如何从另一个表列中选择一个表？

Question

I have a table for seats at a venue but there are multiple venues. I could create one long table with an id for each venue next to each seat but that could make a 2000 long mixed table of venues and seats. So I thought I would create one table for each venue containing their own seating. Such as:

tickets

id | venue_name | seat_id

venueA

seat_id    | section    |    row | seat_number

So I'd like to select the venue table from venue_name ("venueA") and the seat_id. Such as

SELECT seat_id from (select venue from tickets(venue_name));

What I'm trying to capture is the seat_id for a venue so I know which section, row and seat is being requested. The section, row and seat information, as well as the number of seats, can be different for each venue.

I need to be able to identify a seat at VenueA while keeping that separate from the same seat at VenueB.

If that makes sense. This is my first foray into doing sql beyond simple design and interfaces to other people's work. Specifically I'm using postgresql.

Answer 1

Your design is badly done, which is why you're running into this issue. Instead of separate tables for each venue, you should simply have a table of venues. The seats table can then have a venue ID along with the seat information. Something like:

Venues (venue_id, venue_name, etc.)
Seats (venue_id, seat_id, section, row, seat_number)
Tickets (venue_id, seat_id, ticket_id, etc.)

Instead of "ticket_id" for Tickets, you might want to just have an "event_id" that relates to your events and that should uniquely identify any ticket assuming that your system doesn't have any strange business requirements. Also think about the possibility of non-reserved seating if that applies - a ticket might not actually apply to a "seat". That would change the architecture of the tables as well.

If you're going to be doing more of this sort of database design then you should definitely take time to read up on database design and normalization. It's not a trivial thing and the effects of a poor (or good) database design are huge on software development.

Answer 2

I would suggest a schema that included such tables like Venue, Seat, Event and Ticket. I would model Ticket such that it had an EventId and SeatId, an Event would contain a VenueId, a seat would contain a VenueId also.

--- edit to include explanation around testing ---

Apologies if this sounds derogatory, but you can use Explain in PostGre to check the performance of your queries and optimise where appropriate. I would load the DB up with dummy data, possibly have indexes on EventId and VenueId in your child tables to begin with. The documentation for EXPLAIN is here http://www.postgresql.org/docs/8.1/static/sql-explain.html