Re: SQL Humor

Stu wrote:
> Not that I totally disagree with the concept of deprecating char vs
> varchar, but I see this argument used a lot, and there's two flaws with
> it.
>
> 1. Storage size may be cheap and plentiful, but performance should
> always be foremost in the DBA mind. 2 bytes in a single column pf
> storage may not be much, but you also need to write queries that
> retrieve that extra 2 bytes. It's not just disk space; it's also
> memory and CPU.

How much performance difference does it really make? Keep in mind that in a typical table you can declare char a couple of boolean (Y/N) columns at most.

> 2. Failing to appreciate the differences between varchar and char sets
> us on a path of lazy design. If it doesn't matter if I use char(10) vs
> varchar(10), then what's the matter with varchar(50)? How about
> varchar(51) etc? Eventually we could get away with "oh screw it; disks
> are cheap, memory is cheap, CPU's are powerful, let's just put
> everything in an text column and parse it on the fly".

Failing to appreciate the differences between varchar and char sets is an ability to raise the level of abstraction. (BTW, the skill many DBAs lack.) With low level of abstraction you would never quit chaising perceived problems (eg. trying to figure out the "optimal" block size, pondering if

select * from table

is faster than

select col1, col2, ... from table

etc.) Received on Thu Aug 18 2005 - 22:17:37 CEST