This doesn't seem to go away, does it?
If anyone wants to read the paper, I will make it available. It includes scripts and a dmp file.
I think enough time has passed since Hotsos that I will just put it on my website. Something to do this evening I guess, not that there's a shortage of things to do.
The paper is fairly lengthy, but an easy read, with lots of code, with explanations.
As Stephane points out in his post, many database 'designs' start out life as neither normalized nor denormalized: they are just jumbled up mess of columns thrown into tables.
Any thing methodical and requiring thought, even 'denormalizing', will probably improve performance.
I put 'denormalizing' in quotes because to truly denormalize a database, you must first start with a normalized design.
In light of Jared's highly informative presention on why we should normalize for performance (Hotsos 2006) I was struck by this statement.
> Materialized views are an Oracle Silver Bullet when pre-joining tables > together for super-fast response time. > > One issue with highly-normalized, non-redundant Oracle table designs ( > e.g. third normal form) is that Oracle experiences a high degree of > overhead (especially CPU consumption) when joining dozens of tables > together, over-and-over again. > > Using materialized views we pre-join the tables together, resulting in a > single, fat, wide and highly-redundant table. >
Not trying to start a flame war or anything here! While there are certainly "truisms" in the statement above, it does seem to me at first glance to be a statement that feeds into the "normalization hurts performance" mindset.
I have not read the entire article yet.
-- Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist