Martijn Tonies wrote:
Martijn Tonies wrote:
database. I would also bet that 80% of the people who are actually
writing queries with that many joins don't have a solid grasp of the
fundamental principles of relational database design.
Why not? Normalizing gets you -more- tables, not less.
And normalizing is a goal in itself? I've seen plenty of "normalized"
databases which have become a big mess because of the unnecessarily
complex queries you needed to do a relatively simple job.
No, it's not a goal in itself, that's not what I said.
I didn't say that you said that. You stated that "Normalizing gets you
-more- tables". It wasn't mentioned why you wanted to "normalize" the
database in the first place. To me your statement looked like it said
that "normalizing" a database would be a requirement for any database.
This automatically would produce queries with 61+ joins in them.
A lot of the "enterprise level" features can be useful in certain cases,
Normalizing data has nothing to do with "enterprise level", it's a matter
if keeping your data consistent, being able to create proper constraints
at the database, for example.
Normalizing has nothing to do with "enterprise level", but joining
complex views has. Don't ask yourself why you've created the views, just
use them in a join.
So normalize each database because you may want to create constraints in
some situations?
This is the behaviour which causes unnecessarily complex databases,
queries and applications.
If you ask yourself if normalizing a column in a table is useful and if
you really need the constraint and if the view, stored procedure,
function or whatever you use is really useful, chances are that the
application is a lot simpler, faster and easier to maintain.
--
Jigal van Hemert.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
