Skip to main content
Eventify’s MySQL database is built around seven tables that together model every aspect of event management: who can log in and what they’re allowed to do, where events take place, how they’re categorised and tracked, and which attendees hold tickets. The schema is managed entirely through Laravel migrations, so every structural change is version-controlled and reproducible. Run all migrations — and optionally seed sample data at the same time — with a single Artisan command:
The tables below are listed in dependency order. Each table that holds a foreign key is introduced after the table it references, matching the order in which Laravel applies the migrations.

roles

The roles table defines the two access levels in Eventify — Administrator and User — and is the first table created because users depends on it.

users

The users table stores every registered account. Each user is assigned a role via role_id, which defaults to 2 (the regular User role). Soft deletes allow accounts to be deactivated without losing historical records such as tickets. Foreign keys

statuses

The statuses table is a simple lookup table whose values drive the availability label shown on every event listing. Soft deletes let an administrator retire a status value without breaking historical event records.

locations

The locations table records the physical venue of an event. Latitude and longitude are optional: they are populated by the factory during seeding but may be left blank when an event is created manually without geocoding.

categories

The categories table organises events by type. Each event belongs to exactly one category, making it straightforward to filter listings by genre or theme.

events

The events table is the central table of Eventify. Every event is owned by a user, assigned a status, placed at a location, and organised under a category. Foreign keys are set to ON DELETE SET NULL so that removing a related record does not cascade-delete the event itself — the event simply loses its association. Foreign keys

tickets

The tickets table records every purchase or reservation made by a user for a specific event. The quantity column allows a single transaction to cover multiple seats. Both user_id and event_id are required — tickets cannot be orphaned — and soft deletes support cancellation workflows without permanent data loss. Foreign keys

Relationships

The table below summarises every Eloquent relationship implied by the foreign keys above.
Every table in the Eventify schema carries a deleted_at column and uses Laravel’s SoftDeletes trait. Soft-deleted rows are excluded from standard queries but remain in the database and can be restored at any time.