> >> 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.
Of course, a de-normalized design makes it much harder to keep track of the data you're using. So yes, I think a proper normalized design is more flexible. Martijn Tonies Database Workbench Lite for MySQL - FREE developer tool for MySQL! Upscene Productions http://www.upscene.com My thoughts: http://blog.upscene.com/martijn/ Database development questions? Check the forum! http://www.databasedevelopmentforum.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
