Re: best design for seating reservation type database

"Thomas Brown" <tbrown_at_plains.net> wrote in message news:7df9dfd6.0210101403.6da4327a_at_posting.google.com...
> I have a couple of databases that keep track of seating reservations
> for some small local events. I've never been sure though about a
> "best practice" for desiging these types of databases. If, say, you
> have an event that always has 200 seats available, what is the best
> way to build the tables? Should you have a table with 200 rows, one
> for each row from the very start? Or should you start with no rows,
> and assume that if a row is not present, that seat has no data yet (it
> is not yet reserved and therefore is still available)?

I recently read called Data Modelling (G Lawrence Sanders) which gives examples of the exact thing you're talking about. If I remember correctly he advocated something like the following (I dont' have the book to hand, so you may want to get hold of the book to be sure!).

| Event |--------<| Event Seat |--------I-o| Event Seat Resevation |>--I-------| Reservation |

e.g

The 'o' means optional. The 'I' means dependent. For example, an Event Seat Reservation can not exist without both a Reservation and an Event Seat. An Event Seat can optionally have an Event Seat Reservation.(meaning not all seats for an event are necessarily booked). In answer to your question, the 200 seats would be set-up for each event, and then reservations allocated as they are made. Note that here, a reservation can be for more than one seat.

HTH Tobin Harris

> The first way might be a little easier for a human to read, since all
> seats are present and accounted for. The second though, would save on
> database size.
>
> Any thoughts?
>
> Thanks.
>
> Thom
Received on Fri Oct 11 2002 - 12:09:42 CEST