|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Wednesday, May 22, 2013 9:37 AM
Points: 285,
Visits: 1,378
|
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Friday, April 12, 2013 3:55 PM
Points: 46,
Visits: 164
|
|
Solomon,
Great article. I used to get very frustrated with programmers AND DBA's that thought the normalization aspects of relational models would cause a degredation in performance. I know that's a long and not so simple topic, but you have alluded to it here.
Jay Quincy Allen, Managing Partner, ADAMA Systems
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Yesterday @ 9:44 AM
Points: 52,
Visits: 189
|
|
AWESOME! I love this article. Solid, logical, intelligent.
"If I had been drinking out of that toilet, I might have been killed." -Ace Ventura
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Friday, March 08, 2013 2:28 AM
Points: 8,
Visits: 27
|
|
| Brilliant - will circulate to my colleagues rightaway!
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Tuesday, July 26, 2011 5:27 AM
Points: 1,
Visits: 15
|
|
| Thank you for a great article!
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Yesterday @ 10:43 AM
Points: 2,945,
Visits: 10,517
|
|
Columns that are too large also use more CPU time even if they are cached in memory. When you scan a table or index, it has to pass through the CPU, so the more data there is, the more CPU time it takes to process.
I was just looking at the database for a vendor supplied application, and was shocked to see they were using GUIDs in the form of strings as the primary keys for all tables. Each PK is stored in a varchar(36) column, and they even store the dashes in the column. 
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Yesterday @ 8:56 PM
Points: 1,060,
Visits: 4,182
|
|
| Thank you for a great reminder that disk space isn't free! We installed a new SAN at the start of 2010 and it is already full - and I'm sure a lot of it is 'wasted' space. Some of us are old enough to remember when every byte (or even bit!) counted, and this is an excellent explanation.
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: 2 days ago @ 8:31 AM
Points: 3,129,
Visits: 4,312
|
|
Fantastic article. Will circulate extracts hereof to my business users, who all labour under that very misconception. If they could get their way, exact copies of production data would exist wherever they have a need to look (MI data in the production environment, exact copies of production data in the MI environment, etc)
Thanks.
____________________________________________ Space, the final frontier? not any more... All limits henceforth are self-imposed. “libera tute vulgaris ex”
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Thursday, March 28, 2013 3:35 AM
Points: 21,
Visits: 148
|
|
Hi Solomon,
Great article, clear and practical. Alot of common sense that usually never gets taken on board in the design phase.
Just like to add, another potential problem of wasting space when incorrectly defining data types is the issue of clogging up precious network bandwidth.
Many Thanks
|
|
|
|
|
SSC Journeyman
      
Group: General Forum Members
Last Login: Tuesday, March 12, 2013 1:26 PM
Points: 86,
Visits: 473
|
|
Great Article and well explained. I hear 'disk space' is cheap all the time as well. The problem typically stems from the fact that the developers don't fully understand what they they are doing and don't want to clean up; so instead they keep all their intermediate results even though they role their intermediate results forward.
|
|
|
|