Tuning for performance is often feasible, but correcting bad data can get really messy.
What good is bad data that performs pretty well! J -------------------------------------------------- From: "Nuno Souto" <dbvision@xxxxxxxxxxxx> Sent: Friday, October 16, 2009 7:12 PM Cc: <oracle-l@xxxxxxxxxxxxx> Subject: Re: Design Question
Balakrishnan, Muru wrote,on my timestamp of 17/10/2009 2:58 AM:My argument is, production hardware is not cheap (we can buy 1TB for home under $100, but production hardware costs thousands), less overall blocks used improves performance, negligible problem with joining lookup tables.Completely in agreement. Denormalization might save joins but I have yet to see a case where it saved on data. In fact, the opposite is generally the case: it greatly increases the amount of data that needs to be stored and therefore the amount of I/O used to manage it. If that increase conterbalances any perceived or actual overhead of joins is wide open for debate and there is no final answer: each case has to be examined on its own conditions. Normalization was not "invented" to save disk space. It was initially intended to save the amount of I/O one has to perform to manage or retrieve any given information. "Amount of I/O" is not the same as "disk space" and I know for sure which one causes performance problems.-- Cheers Nuno Souto in sunny Sydney, Australia dbvision@xxxxxxxxxxxx -- //www.freelists.org/webpage/oracle-l
-- //www.freelists.org/webpage/oracle-l
