From: Martijn Tonies
Date: February 1 2010 3:05pm
Subject: Re: 50 things to know before migrating from Oracle to MySQL
List-Archive: http://lists.mysql.com/mysql/220529
Message-Id: <02aa01caa350$076aa060$6101a8c0@martijnws>
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit

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

Yes, that's a good thing, unless it's an OLAP database. It improves
data consistency and avoids NULLs in storage, which is good.

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

Constraints are a good thing.

> This is the behaviour which causes unnecessarily complex databases, 
> queries and applications.

Unless you don't value your data very much, I consider normalizing,
database constraints etc a "pro", not a "con".

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



With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!

Database questions? Check the forum:
http://www.databasedevelopmentforum.com