Re: Sizing of char,varchar and text fields

We have had similar needs in many cases. We have resorted to a separate table with shorter char-fields, an index and a "line number" field to store such data. We of course store the index in the main table. (Sometimes we have found it easier to use a serial field for the "line number" and the index is often the primary key of the main table.) This is a lot of work (programming) compared to what a higher limit on varchar whould have given us, but it avoides the overhead of a text/binary field in storage space and works also on SE. Would have loved to see a lightweight blob implementation, a higher max size on varchar or some other solution to this. dBase/MS Access and other PC databases has "memo" fields for this. There may be some problems releated to the SQL standard in implementing this, but perhaps Informix could work it out some day? Nils.Myklebust@ccmail.telemax.no NM-data, Dalsbergstien 7, N-0170 Oslo, Norway My opinions are those of my company In article <412gpi$i50@sclinux.blm.gov>, <gslagel@sc.blm.gov> writes: > > I'm trying to figure out the best way to handle some large fields in my > > database. VARCHAR would be perfect if it didn't have that 256 char limit. > > CHARACTER is plenty long (32000) but I don't want it taking up 32000 bytes > > every > > time I put a 10 character name in the field. > > > > How about TEXT???? I can't find out for sure how much room text fields > take. > > I heard a rumor that they take up 2K of space as soon as you put in a 10 > char > > name. Is that true? > > > > Are there any clever solutions out there? > > > > > > "Alexander J. Oss" <alex.oss@films.com> writes: > I believe that is not just a rumor about taking up at > least one block for each BLOB entry (and our block size > is also 2k). > > You could try keeping the files outside of the database, > and store only the filenames inside...