RE: Wide Vs. Narrow Tables
Date: Tue, 15 Sep 2009 08:57:51 -0400
Message-ID: <SNT115-DS8DB9084593DCC3EA71633A6E30_at_phx.gbl>
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
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
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Sep 15 2009 - 07:57:51 CDT