RE: Large databases

Normalization is relative. Depends who you talk to and what you are trying to do. Normalization is necessary but only up to a point.

When you said the normalized database performed faster, how do you know it will perform slower if not normalized, did you test it?

Also, Normalization is not a one step process, you can normalize up to first normal form only or second normal form only.

After designing my database, the first thing the Access DBA said was: "I have a book about designing databases and a chapter about normalization. You should read it." and then he showed me his ER Diagram with neat little 4 column tables. The funny thing is, the tables have 4 columns not because of normalization but because he would only put a max of 4 columns worth of information in a table. As in:

Person pk
Person full name
Person DOB
Person sex

--
Lyndon Tiu


Quoting Jared.Still_at_radisys.com:



> I would suspect some fault application design if they were 

> joining 13 tables.  That is not normally necessary.

> 

> Nomalized databases, in my experience, are faster than

> most people think or expect, including me.

> 

> One such example from several years ago was an application

> we built from the ground up, including the schema design.

> 

> The app had to accept packets over an X25 link, adjudicate

> a pharmacy claim and send the results back to the pharmacy.

> 

> The allowable time for an end to end transaction was 9 seconds.

> 

> IIRC, it usually ran in less than 2 seconds.

> 

> That database was for the most part normalized, or as normalized

> as we were able to make it.  It was our first project with an

> RDMBS.

> 

> There was one table we couldn't quite figure out how to normalize

> properly. The code that accessed that table was ridiculously

> complex,

> and would have been significantly simpler had we normalized.

> 

> There always seems to be a lot of anecdotal evidence proclaiming

> that normalization cannot be used to create a performant

> database,

> but there never seems to be any numbers to back it up.

> 

> The closest I've seen is Gurry and Corrigan's references to

> putting

> all code lookup tables into a single table to speed up a system.

> ( http://www.oreilly.com/catalog/oracle2/ )

> 

> At that, it was a minor infraction of normalization.

> 

> Maybe this would make a good project?

> 

> Jared



-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Lyndon Tiu
  INET: ltiu_at_alumni.sfu.ca

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).