Subject [firebird-support] Re: varchar fields and memory
Author kaczy27
Hi, Helen

> As a designer, I wouldn't define a 1K varchar for data that was
likely to
> be only 50 bytes; and I wouldn't use a 1K varchar as a grouping
or sorting
> criterion for 100,000 records (that would be a verrrrrry expensive
> non-indexed sort!!); and, if I were going to be drawing sets of
> magnitude I'd definitely store variable text of that size in blobs.
What are the advantages of using blobs?

I need to store generic data sometimes they are integers that need
to be summed, or averaged, sometimes they are texts that need to be

Since both the number and type of parameters is unknown I can't
define an tables design, and I had to resort to an object-property-
value relation. Each value has an index so I perform sorts and
grouping on a subset of full table only. Depending on the property
type I do casts to specific type and perform an operation on it.

I understand that the work on this subset is performed without an
index help - but the blob can't be indexed also.

The numbers of records I am talking about aren't large - up to
10.000 records to be summed, but if firebird need 1k per record...
do cast(varchar(1024) as integer) also take 1k in memory?

Any design suggestion?

CUN Kaczy
> ./heLen