 |
 |
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, quadruples, etc.? > > 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 following..." > > A good database design will go a long way... Andy.