http://qs321.pair.com?node_id=131199


in reply to Question about properly laying out a database

You guys are just too much work! :-)

While I also would use MySQL or Postgresql for something like this it really doesn't matter. How to organize the data doesn't matter either.

Stamp_Guy, I would recommend just focusing on organizing the data so it's most convenient for you to implement the search features you need. If the site gets less than a few hits per second, then with only 500 entries in the database it'll be super fast no matter how you do it. How big is the whole database? If you run mod_perl you could actually use Storable and just load the whole thing into memory every time the file gets updated (although with DB_File and BerkeleyDB you can get either shared memory BerkeleyDB foo and/or the filesystem cache).

But I digress; the point is that all that doesn't matter. Save the fancy design for when you need it. Focus on getting the thing done and implementing the needed functionality.

 - ask

-- 
ask bjoern hansen, http://ask.netcetera.dk/   !try; do();

Replies are listed 'Best First'.
Re: Re: Question about properly laying out a database
by joealba (Hermit) on Dec 12, 2001 at 22:17 UTC
    The design doesn't have to be fancy.. but it does have to be correct. Organizing the data in a normalized way will make it faster, easier to implement, and MUCH easier to extend later.

    Always think ahead... *especially* when you are dealing with people in sales. :) Out of 10 projects developed for sales purposes, all 10 of them will want extra functionality after the project is completed. I absolutely guarantee it (or your money back). hehehe

    Update: Thought I'd clarify on the "easier to implement" bit. Okay, you'll have to do an extra lookup to match a few keys to their values -- like matching the make_id to the make text string. But, when it comes time to write search code, it's faster and easier to develop a search that does a numerical match, rather than some kind of regexp match on the string!