Re: Normalized Databases = Poor Performance?

  • From: "Jared Still" <jkstill@xxxxxxxxx>
  • To: post.ethan@xxxxxxxxx
  • Date: Thu, 4 May 2006 12:53:30 -0700

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.


On 5/4/06, Ethan Post <post.ethan@xxxxxxxxx> wrote:

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

Other related posts: