Re: SQL Humor
Date: Sat, 20 Aug 2005 00:52:07 +0200
Message-ID: <tfocg15f6a835vd0r62rmq169ii43e4sfh_at_4ax.com>
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