On 5/22/06, Houghton,Andrew <[log in to unmask]> wrote:
> > From: Code for Libraries [mailto:[log in to unmask]] On Behalf
> > Of Ross Singer
> > Sent: 22 May, 2006 11:58
> > To: [log in to unmask]
> > Subject: Re: [CODE4LIB] Musings on using xISBN in our Horizon
> > catalog
> > Given the size of both datasets, we are still talking about a few
> > seconds per query with most currently available SQL databases. But
> > what happens when the size of the catalog doubles, triples,
> Wait. A few seconds? You're kidding, right? An indexed look up of
the group id
Oops, flagrant typo revealed. That should have read "... We are still
talking about a few milliseconds per query..." If only my fingers
could read my mind...
> Just so we're clear, we are talking about, at most, .5M rows that are
perhaps 50 bytes > wide, with internal data. That translates to ~25
megabytes for the table, and the
> indexes would be /maybe/ 5 megs each.
There is more than one way to solve a problem. You are free to use an
unnormalized database design if that is adequate for your needs. But
why would you want a database ~25 MB with 10MB of indexes, when you
could get the same results from a normalized database design whose
storage requirements were *roughly* 4 times less and get better
scalability should your requirements change in the future?
Yes, I can hear the come-back, "disk space is cheap", but someone pays
for it at some point in time. I can agree to disagree with using an
unnormalized database design and as I indicated in my first post, "If
I were setting up the SQL database, I would probably do the
> > A good database design will go a long way...