Which Relationship Are You Even Talking About?

Many seats share one seat type, and a single seat can only ever be one type. That settles it: many-to-one.

The Same Two Classes Can Hold More Than One Relationship

Before asking "what's the cardinality between these two entities," there's a question that has to come first: which relationship, exactly?

Picture a Group class at a company like WhatsApp. A group relates to User in several separate ways at once: who created it, who its members are, who its admins are, and who it has blocked. Each of those is its own relationship, and each one can have its own cardinality. Asking "what's the cardinality between Group and User" without saying which one of these you mean doesn't have one answer.

Show and Auditorium Hide the Same Trap

Show holds a single Auditorium, not a list. That alone settles half the question: one show plays in exactly one auditorium.

The other direction is where it gets interesting. How many shows does one auditorium have? That depends entirely on which relationship is meant.

One reading is "the show currently playing right now," which would make it one auditorium to one show. But that's not what a booking platform actually needs. A booking platform has to store every show that auditorium will ever run: this morning's, this evening's, and every future slot still open for booking. That's a job for a theatre-management system's "what's on screen right now" feature, not this one.

Once the real relationship is the full set of shows an auditorium hosts over time, the cardinality flips: one auditorium can have many shows, and one show belongs to exactly one auditorium. Many-to-one.

Movie and Show Follow the Exact Same Shape

One show is of exactly one movie. But one movie, especially a big release, can have thousands of shows running across every theatre on the platform.

Same shape as Show to Auditorium: many-to-one.

When It's Genuinely One-to-One, Either Side Can Hold the Key

For a true one-to-one relationship, it doesn't matter which table gets the foreign key. A join solves it either way, so there's no wrong answer between the two options.

In practice, this isn't even a choice to make. Whichever class actually declares the reference in code is the one whose table gets the foreign key. If Show holds an Auditorium field, the foreign key lands in the shows table, not the other way around.

One real wrinkle is still open here, worth sitting with rather than skipping past: what happens when two entities reference each other in both directions at once, City holding a list of Theatre, and Theatre also holding its own City back? That's a different problem from picking one direction, and it doesn't have an answer yet.

The Mapping Class Twist: ShowSeat's Cardinality

ShowSeat holds a single Show, not a list, which settles part of the picture immediately: one ShowSeat object relates to exactly one Show.

The real question is the other side of both relationships: how many ShowSeat objects relate to one Show, and how many relate to one Seat? One hint worth sitting with first: for a mapping class, the cardinality it has with each of the two entities it connects always comes out the same shape. Work out one side, and the other side follows the identical pattern.