RE: Wide Vs. Narrow Tables

  • From: "Michael McMullen" <ganstadba@xxxxxxxxxxx>
  • To: "'oracle-l'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 15 Sep 2009 08:57:51 -0400

We?re a DSS shop and the majority of our problems have been with not taking
growth into consideration. I?ve finally got them convinced that you can?t
scale a server/application if you have unlimited growth. Our default now is
13 months data retention, with all deletes, archiving in place before
production. 

 

  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Kellyn Pedersen
Sent: Monday, September 14, 2009 12:57 PM
To: oracle-l
Subject: 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 

 

 

Other related posts: