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
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.