Re: LONG vs. Multiple VARCHAR2

From: Hans Forbrich <forbrich_at_supernet.ab.ca>
Date: 1995/08/07
Message-ID: <4065h9$h3e_at_tibalt.supernet.ab.ca>#1/1


Tim Boemker (tim_boemker_at_zacatecas.optimum.com) wrote:
> In article <402p4q$95b_at_kaiwan.kaiwan.com>
> contillo_at_kaiwan.com (Michael Contillo) writes:
 

> > My question is: Given the situation, what are the advantages and
> > disadvantages of using a LONG datatype to store freeform text?
 

> There are restrictions on LONG data, one of which you know already:
> they can't be pattern matched. They can't be indexed. They can't
> occur in subqueries. There can be at most one in a table. With OCI,
> there's no way to find out how big they are. The advantage, of course,
> is that you can store arbitrarily large amounts of text. If you decide
> to use LONG, you might want to put all LONG data in a separate table
> (with a length field) and put foreign keys in other tables.
 

> Tim Boemker
> Optimum Group
> (513) 577-7785

Also, you can't use INSERT from SELECT of a long column, have a number of SQL*Net restrictions, etc.

The other side of it ... it's painfully difficult to simulate LONG using an arbitrary bunch of VARCHAR2(2000)s. Since LONGs can contain up to 2Gig, that translates into an awful lot of 2K strings. :-)

This is another case of 'do your analysis'. A varchar2(2000) can handle 1 screen of the old 80x24 terminals. I have found that a significant amt of info can be crammed into that size. If the app needs more, then a) question it & b) put it into LONG

My .02

/Hans Received on Mon Aug 07 1995 - 00:00:00 CEST

Original text of this message