Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: database design issue: one big table vs hundred of smaller tables

by ask (Pilgrim)
on Nov 26, 2001 at 07:04 UTC ( #127472=note: print w/replies, xml ) Need Help??


in reply to database design issue: one big table vs hundred of smaller tables

I would probably go with one table for the categories and a table for each distinct type of item group. (It looks like the items are too different to go into one big table).

For fast searching, look at the latest Swish-E. You can do a "streaming" database dump formatted as simple XML and have swish-e read and index that.

In my experience you end up doing table scans if you need any kind of advanced searching. If you insist on doing it with SQL, then be sure to get as few tables as possibly (or group them as much as possibly based on how they are going to be used). You don't want to run a thousand queries to search all categories.

 - ask

-- 
ask bjoern hansen, http://ask.netcetera.dk/   !try; do();
  • Comment on Re: database design issue: one big table vs hundred of smaller tables

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://127472]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2022-01-19 15:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:












    Results (55 votes). Check out past polls.

    Notices?