Re: SQL Humor

    Once you start dealing with text of length > 4000 (Unicode) 8000 (ANSI), you are practically working with documents not attributes, so this data should be stored in a document management system with numeric or URL pointers stored in the relational database. The TEXT datatype is there for large blobs of data for those so inclined, but it's an entirely different case usage than VarChar.

    On the application side, if you are storing gigabytes or even 10s megabytes of data in a string or array, then it is time to start re-considering the application design.

"Mikito Harakiri" <mikharakiri_nospaum_at_yahoo.com> wrote in message news:1124470860.929327.139870_at_f14g2000cwb.googlegroups.com...
> JT wrote:
>> 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.
>
> Think about it for a minute. You have varchar2 limited to 4000 bytes.
> Then you have text to cover 4K to 2G range. Then you have to rely on
> some other option to be able store data bigger than 2G (split it into
> chunks in your application????).
>
> If you suggested such a design to programmic language community, you
> would be laughed at. Of course, you have a performance disclamer to
> back you up, while in reality there is nothing that makes text datatype
> inherently less performant than varchar2. In fact, those ugly length
> limited datatypes are just artifacts of the early SQL days, when
> Fortran was the most popular programming language, and datatypes with
> dynamic memory managenent were yet to become mainstream.
>
Received on Fri Aug 19 2005 - 19:45:43 CEST