Data model · derived from the v5 redesign
What an event stores now.
The v5 redesign — tickets & tables, all-in pricing, free transfers, honest refunds, per-venue deposits, buyer protection, payouts that settle 24–48h after the night, verified-host & women-only audiences, post-event reviews and the door scanner — asks the data layer to hold far more than today's single Event row. This is the proposed structure: the existing Event kept and extended into a hub, with commerce, trust and supply factored into their own normalized entities. Mined from all 101 screens / 14 flows of joinmein-redesign.html. Reference only — no code changed.
01
Why the model has to grow
Today an event is one flat row with no money, tickets, tables, reviews or host identity. v5 needs all of it.
02
The event, as a hub
Event stays the centre. Everything priced, booked, paid, scanned or rated hangs off it as its own table.
Event
core · extended
Identity, time, place, audience & safety, lens (live broadcast vs hosted plan), host type, series, and the commerce mode — but never the money itself.
Ticketing
priced inventory
TicketTierReleaseWaveOrderTicketTicketTransferWaitlist
Tables
venue reservations
TableInventoryTableBooking
Money & protection
settlement
RefundPayoutDispute
Trust & after
reputation
ReviewHostProfileScanAttendanceOfferRedemption
Supply
host side
VenueVenueOfferEventSeries
Taxonomy
kept
EventCategoryEventSubcategoryEventTag
Feature layers
dating · world cup
MatchLiveLocationShare
03
The entities, field by field
Money is stored as integer minor units (cents) plus a currency; "all-in" means base + fee breakdown is persisted.
04
Status vocabularies (enums)
Every order, ticket, booking, refund and payout moves through an explicit state machine.
05
Decisions & open questions
The modelling calls worth a second look before this becomes a migration.