Event Espresso 4 Pro keeps the same relational schema across the Pro tier: events in wp_esp_event, datetimes in wp_esp_datetime, registrations in wp_esp_registration, transactions in wp_esp_transaction, payments in wp_esp_payment, attendees in wp_esp_attendee, and custom question answers in wp_esp_answer. Pro add-ons (Multiple Event Registration, Promotions, WP-User Integration) layer additional tables that still respect the same foreign-key conventions.

SleekView reads wp_esp_registration as the primary entity and joins event title, ticket name, transaction status, and attendee email through EVT_ID, TKT_ID, TXN_ID, and ATT_ID. Custom question answers from wp_esp_answer promote to columns scoped per question. Promotions and discount codes from Pro add-ons join through the transaction.

Inline edits write through EE4's CRUD layer where it exposes hooks (registration status, check-in flag, notes), and fall back to direct wp_esp_registration writes with conflict detection where no public method exists. Front-end registration flows, transactional emails, and EE4 Pro add-ons keep firing because the grid uses the same schema EE4 maintains.

Event Espresso 4 Pro models event sales with the kind of relational rigor that lets a serious operation grow. Events, datetimes, registrations, transactions, payments, attendees, and custom answers each get their own table with proper foreign keys. That structure is the foundation for trustworthy reporting, but it is also what makes the tab-by-tab admin feel like seven screens chasing one question.

An organizer planning next Saturday's gala does not want to bounce between registration list, transaction list, and attendee list to know how many VIPs have not paid. Finance does not want to reconcile wp_esp_transaction and wp_esp_payment through CSV exports. Door staff at a multi-day event do not want to switch event context every time an attendee arrives.

Treating the EE4 schema as a real grid that joins on the keys EE4 already maintains turns those tabs into one workflow. Saved views become the rituals of each role, inline writes route through EE4's own hooks where available, and the team spends less time learning the admin and more time running the event.