Wide Vs. Narrow Tables

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@xxxxxxxxx> wrote:


From: Jared Still <jkstill@xxxxxxxxx>
Subject: Re: Speaking of New Features
To: ahbaid@xxxxxxx
Cc: chet.justice@xxxxxxxxx, "oracle-l" <oracle-l@xxxxxxxxxxxxx>
Date: Monday, September 14, 2009, 10:38 AM




On Sat, Sep 12, 2009 at 8:04 AM, Ahbaid Gaffoor <ahbaid@xxxxxxx> 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

 

Other related posts: