Path: news.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!newsfeed.news2me.com!canoe.uoregon.edu!logbridge.uoregon.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail
From: tbrown@plains.net (Thomas Brown)
Newsgroups: comp.databases.theory
Subject: best design for seating reservation type database
Date: 10 Oct 2002 15:03:12 -0700
Organization: http://groups.google.com/
Lines: 18
Message-ID: <7df9dfd6.0210101403.6da4327a@posting.google.com>
NNTP-Posting-Host: 216.41.128.219
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1034287392 27760 127.0.0.1 (10 Oct 2002 22:03:12 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 10 Oct 2002 22:03:12 GMT
Xref: newsfeed1.easynews.com comp.databases.theory:22918
X-Received-Date: Thu, 10 Oct 2002 15:03:07 MST (news.easynews.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)?

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