Re: SQL Humor

From: Hugo Kornelis <hugo_at_pe_NO_rFact.in_SPAM_fo>
Date: Sat, 20 Aug 2005 00:52:07 +0200
Message-ID: <>

On 18 Aug 2005 15:50:39 -0700, Mikito Harakiri wrote:

>Stu wrote:
>> if you disregard the differences here
>> because of substantial resources, why bother with any sort of datatype
>> at all? If a varchar(50) will do the trick of a char(10), what's 42
>> extra bytes? In the days of terabytes sized RAID arrays, why not use a
>> varchar (8000) for everything? Why use an integer if a varchar will
>> do? Obviously at some point, there will be a performance impact; why
>> not be disciplined enough to strike at the lowest level of that curve
>> and use the least expensive resource that is the best fit for your data?
>Humans are notoriously bad at storage management. Storage layout is
>something that has to be hidden and managed automatically. When did you
>specify memory parameters for your web browser program (Let see: 10M
>for fonts, 15M for web pages cache, 5M for cookies, or, wait a minute,
>maybe 2M for cookies would make my browser faster?)

Hi Mikito,

What DBMS are you talking about here? Please remind me never to take a job that involves managing one of those....

BTW, Internet Explorer does allow you to specify maximum cache space...

>I want a string datatype, and can't possibly predict (and don't really
>care) how long it would be. Is it so difficult to design a RDBMS engine
>that would allow me to declare a string of arbitrary length with some
>rudimentary intelligence as far as storage is concerned?

Such a string type exists. In SQL Server, and I bet in all other major databases as well.
But the flexibility comes at a price: performance suffers. So if you care about performance, you should only implement this flexibility where you need it.

Best, Hugo


(Remove _NO_ and _SPAM_ to get my e-mail address)
Received on Sat Aug 20 2005 - 00:52:07 CEST

Original text of this message