Wide Vs. Narrow Tables
From: Kellyn Pedersen <kjped1313_at_yahoo.com>
Date: Mon, 14 Sep 2009 09:57:27 -0700 (PDT)
Message-ID: <493520.76868.qm_at_web32005.mail.mud.yahoo.com>
Taking a *Twist* on this subject...
I've been performing a lot more design at my last two companies and I find wide tables with 100's of columns that should have been more effieciently designed and broken into multiple tables the center of many performance problems. There are tons of recommendations on what great performance you can get in a data warehouse by creating tables with 100's of columns, but no one seems to take the time to incorporate the important supporting structures to guarantee performance or rarely take growth into consideration. Why is it that people so rarely take the natural and one guaranteed trait of databases- GROWTH into consideration to their design? How often do we hear, "Well, it worked great when we first went to production- what happened?" How easy it is for us, as DBA's to look at a table, 100's of columns wide and see the difference of behavior when it was 20MB in size vs. 20 or 200 GB! The issues with concurrency, maintenance, I/O- should it be that difficult to understand? How often have you, as DBA's had to rewrite code or redesign the physical object to correct the problem due to growth not being taken into consideration when the original design was conceived?
Kellyn Pedersen
Multi-Platform DBA
I-Behavior
Date: Mon, 14 Sep 2009 09:57:27 -0700 (PDT)
Message-ID: <493520.76868.qm_at_web32005.mail.mud.yahoo.com>
Taking a *Twist* on this subject...
I've been performing a lot more design at my last two companies and I find wide tables with 100's of columns that should have been more effieciently designed and broken into multiple tables the center of many performance problems. There are tons of recommendations on what great performance you can get in a data warehouse by creating tables with 100's of columns, but no one seems to take the time to incorporate the important supporting structures to guarantee performance or rarely take growth into consideration. Why is it that people so rarely take the natural and one guaranteed trait of databases- GROWTH into consideration to their design? How often do we hear, "Well, it worked great when we first went to production- what happened?" How easy it is for us, as DBA's to look at a table, 100's of columns wide and see the difference of behavior when it was 20MB in size vs. 20 or 200 GB! The issues with concurrency, maintenance, I/O- should it be that difficult to understand? How often have you, as DBA's had to rewrite code or redesign the physical object to correct the problem due to growth not being taken into consideration when the original design was conceived?
Kellyn Pedersen
Multi-Platform DBA
I-Behavior
- On Mon, 9/14/09, Jared Still <jkstill_at_gmail.com> wrote:
From: Jared Still <jkstill_at_gmail.com>
Subject: Re: Speaking of New Features
To: ahbaid_at_att.net
Cc: chet.justice_at_gmail.com, "oracle-l" <oracle-l_at_freelists.org>
Date: Monday, September 14, 2009, 10:38 AM
On Sat, Sep 12, 2009 at 8:04 AM, Ahbaid Gaffoor <ahbaid_at_att.net> wrote:
In tables with hundreds of columns
I would say your pain started right there.
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Sep 14 2009 - 11:57:27 CDT