best design for seating reservation type database

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)?

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 Thu Oct 10 2002 - 17:03:12 CDT