Re: SQL Humor
Date: Thu, 18 Aug 2005 22:25:28 GMT
Message-ID: <sV7Ne.91817$G8.36865_at_text.news.blueyonder.co.uk>
"Mikito Harakiri" <mikharakiri_nospaum_at_yahoo.com> wrote in message
news:1124402576.470238.211960_at_o13g2000cwo.googlegroups.com...
> Hugo Kornelis wrote:
>> Many companies use a short mnemonic code for their customers. The use of
>> a short mnemonic code for products is not uncommon either. Imagine a
>> customers table with 10,000 customers, a products table with 5,000
>> products and an orders table with a few million rows. Now would you
>> prefer char(6) or varchar(6) for CustomerCode? And char(5) or varchar(5)
>> for ProductCode?
>
> But if lookup table cardinality goes up, then, the storage factor
> char(n) vs varchar(n) goes down! Perhaps, you can convince me that the
> effect of the two trailing bytes is not miniscule, as I previously
> thought, but it just can't be significant. Any benchmark demonstrating
> that the performance degradation is not in single percentage digits is
> welcome.
>
Surely, when developing a database application and performance tuning it sqeezing every single performance point out of the database is worthwhile. Everytime that you make a decision which costs a percent of two of performance you degrade your database performance. Given enough of these compomises the database performance will drop significatly, I've seen this happen for real on databases with hundreds of thousands of rows, the performance degraded so much that the application became unusable. A few minor tweeks here and there and the program was running faster than it had ever run before.
It may seem that it's a very academic kind of argument but in real terms the more pedantic and performance oriented the DBA is the better the final product will function.
Yes, you can always throw more kit at a problem, but when you can litterally flick a switch or two and boost the performance it's worth doing. To do otherwise could be contrude as neglegence!
Regards
Colin Dawson
www.cjdawson.com
Received on Fri Aug 19 2005 - 00:25:28 CEST