Mr. Shawn H. Corey wrote: > On Fri, 2008-11-14 at 14:30 +0000, Mark Goodge wrote: > >> I wouldn't try to arbitrarily normalise the database for SQL >> efficiency. >> In a real-life situation, it's more important that the database >> design >> reflects your actual workflow and business requirements. Having a >> field >> that's empty 50% or more of the time is far less of a problem than >> not >> being able to process a sale because your database structure is too >> inflexible :-) >> > > I agree. Remember hardware is cheap, software expensive. It's always > cheaper to add more hard disks than it is to create the software to deal > with an inflexible design. > > > Thank you both for your comments.
I agree that reality will eventually force me to settle for the hardware-, not software-expensive solution. It was more of a theoretical question. I've been researching this on and off for quite some time now, and have never found a definitive resource for solving this kind of problem. Apparently, not ever everyone lies awake of these kinds of things :) In addition: I believe in the ultimate flexibility of fully normalised design over a solution that is cheaper to implement. The latter may work for a long time, but if/when the day comes that your requirements change or hacks need to be applied, I would think that a normalised database will allow you to upgrade the design much more easily than a non-normalised one. Stijn -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
