Events can potentially have multiple addresses (not exposed anywhere to the user, but supported in the backend). When looking up an event, we currently use JOINs to obtain all the data about an event and its addresses. However, this approach is cumbersome because this is a one-to-many relationships, and we'll add more similar relationships to this table in the near future (T334143). DBAs recommended using separate queries on each table instead (thus decomposing the JOINs), as it's actually better than the single-complex-query approach.
Acceptance criteria
- (no need to QA) The code uses multiple queries to retrieve information about the events, instead of a single query with JOINs
- Everything related to addresses (add, remove, view; both in the API and all relevant pages) still works correctly
