Database Design Meeting Notes

Date: 2026-03-18
Note Taker: Oğuz Özer

Participants

• Oğuz Özer
• Mehmet Kaan Ünsel
• Mehmet Akif Yıldırım
• Cansu Er
• Buğra Keser
• Sevde Pekköse

Agenda

• Review the latest database design for the Social Event Mapper project
• Finalize core entities and relationships
• Discuss event management, participation, invitation, and notification structures
• Evaluate support tables for comments, feedback, favorites, and location handling
• Agree on the final schema direction for implementation

Discussion Summary

During the meeting, the team reviewed the latest version of the database design for the Social Event Mapper project. The discussion focused on building a flexible and scalable structure that supports user management, event creation, participation workflows, invitations, notifications, and user engagement features.

The users table was defined as the core authentication-related table, storing basic account information such as username, email, phone number, password hash, login information, and account status. To keep profile-related information separate from authentication data, a dedicated profiles table was introduced. This table stores display name, bio, and avatar URL for each user.

For authentication and session tracking, the sessions table was designed to manage active login sessions with token, expiration, device information, and active status fields.

The main event structure is centered around the events table. It includes event metadata such as host, title, category, description, time range, image, event type, status, capacity, and constraints like minimum age and preferred gender. The table also includes locationType and version_no, which were discussed as important for both location flexibility and event version tracking. The team agreed that event_uid would be useful for versioned tracking across updates.

To support additional event restrictions, an eventConstraints table was included. For user participation flows, the eventParticipations table was designed to track which users joined which events, their participation status, reconfirmation information, and the latest confirmed event version.

Because events may involve location-based routing or multiple points, the eventLocationPoint table was added to store ordered geographic points and addresses for an event. This supports both single-location and route-based event scenarios.

For classification and discoverability, the schema includes eventTags and eventCategories tables. Categories represent the main event grouping, while tags provide more flexible descriptive labeling.

User interaction features were also covered. The favoriteEvents table allows users to save events. The favoriteLocations table enables users to save frequently used locations. The invitations table supports host-driven invitations with message, status, and expiration information. The joinRequests table supports private or approval-based participation workflows, allowing users to request access to events and hosts to manage those requests.

The team also discussed post-creation communication and engagement features. The notifications table was added to store user-facing notifications related to events, along with delivery method, read status, and deep links. The eventComments table supports comments and threaded replies through parent_id, while likes_count enables lightweight engagement tracking.

For event attendance validation, the tickets table was included to generate QR-code-based tickets linked to participation records. The feedbacks table was designed for collecting post-event ratings and written feedback from participants.

One major design decision was the addition of the eventHistory table. This table mirrors the event structure and is intended to preserve previous versions of an event whenever updates are made. This supports traceability and version-based participant reconfirmation.

Finally, the categorySuggestions table was proposed to allow users to suggest new categories, along with an optional explanatory message. This makes the system more adaptable over time.

Overall, the schema was considered comprehensive enough to support the main user flows of the platform, while also leaving room for future refinement during implementation.