Richard Heyes wrote:
I do not agree that creating a database which is normalised to3NF is a
waste of time.
It isn't always, but it is sometimes. When time is a (significant)
factor, getting something up and running (which has acceptable
performance) may be more impotant than creating a technically perfect
solution. In fact creating something that is technically perfect is
often just a pipe dream for programmers.
> On the contrary, a totally un-normalised database is nothing but a
problem waiting to bite you in the a**e.
So you can:
a) Create something that gets you to market as fast as possible that is
"good enough".
b) Optimise/adjust the structure later.
IME though, b) rarely happens.
> Computer systems have a habit of
growing over time
Really?
...and if you don't follow the rules of normalisation your database
will end up as the biggest bottleneck.
Granted it's more likely, but not a given. You just need developers who
have discipline, oh and a good memory helps.
Anyone who doesn't know how to reach 3NF shouldn't be designing
databases.
Rubbish. It helps, in particular for how you can optimise you structure
without duplicating data (too much), but shouldn't be a requirement.
Me personally I've always found it very productive to take a few hours
before I begin coding a project, to roughly flow-chart the basics of the
application, and then layout the db on paper to get a graphical view of
the tables I'll need, how they relate or don't relate to one another.
That way when I do actually create the db I'm usually at 3NF.
--
Mark
-------------------------
the rule of law is good, however the rule of tyrants just plain sucks!
Real Tax Reform begins with getting rid of the IRS.
==============================================
Powered by CentOS5 (RHEL5)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
