Re: SQL Humor

There is a TEXT datatype that supports up to 2 GB. However, such free form datatypes require more meta data overhead, and it's bad design practice to store blobs of text in a relational database.

"Mikito Harakiri" <mikharakiri_nospaum_at_yahoo.com> wrote in message news:1124405438.921335.308080_at_g47g2000cwa.googlegroups.com...
> 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?)
>
> 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?
>
Received on Fri Aug 19 2005 - 16:57:49 CEST