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
