> >> 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.
Database Workbench Lite for MySQL - FREE developer tool for MySQL!
Database development questions? Check the forum!