Hello Lester,

Monday, May 16, 2005, 7:05:49 AM, you wrote:

> Geoff Worboys wrote:

>> This is of course way too fuzzy a measurement to be taken
>> seriously. Lots of GUI stuff in the way of both tests along
>> with caching issues and so on. OTOH there is obviously a
>> cost involved. Real testing is required, with investigation
>> of various options to avoid the pitfalls.

> Hopefully we are throwing in enough evidence that it's not a simple
> yes/no and we do need to be able to enable or disable in a number of
> demonstrable situations.

I think the best way would be to be able to define a BLOB as
compressed or uncompressed when you are creating the field. Having a
database flag or server configuration doesn't make sense to me. Simply
adding a WITH COMPRESSION to the BLOB definition would suffice for me.

The reason why I would prefer a flag per BLOB field(not row) is that
I'm currently using JPEG2K to store the images, and obviously they are
already well compressed and don't require to use the compression
algorithm. But I also have a document management system that uses the
same database and in that BLOB field users can store anything(text,
images, documents, video, etc...). And, at the moment we are
compressing the data before placing it in the blob, but if Firebird
would perform that task, then that would mean a little less code to
manage on my part.


--
Best regards,
Daniel Rail
Senior Software Developer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)