I am trying to store Images (JPG-BMP) inside a field.  What is the best field type to use?  I tried using Blob but the *.BLB file are growing so fast
even when storing 5 images in 3k records table.  So, should I use "ftGraphic" instead? And what are the differences?  I am looking for the
smallest/fastest to access, etc.  This question goes for DBISAM3 and EDB 1.08.

Abdulaziz


What size are the images, and what is the blob block size?

In DBISAM I used MEMO for everything of a blob nature, in ElevateDB I've separated text into CLOBs and images, tables etc into BLOBs

Roy Lambert

Roy,

<<What size are the images>>
They are between 60 to 300 KB.  I use


<<, and what is the blob block size?>>
I use the default block size 512.

However, this does not satisfy my needs when it comes to the size of the BLB file.  It grows so fast by transactions.  I tried to do some repair but
that did not fix the problem.  I even played with the block size knowing the fact small blocks sizes means small files with slow performance and vies
versa.  But still does not satisfied with the results.  I am talking here about DBISAM3 and trying to make things better with EDB.

Abdulaziz,

<< I am trying to store Images (JPG-BMP) inside a field.  What is the best
field type to use?  I tried using Blob but the *.BLB file are growing so
fast even when storing 5 images in 3k records table.  So, should I use
"ftGraphic" instead? And what are the differences?  I am looking for the
smallest/fastest to access, etc.  This question goes for DBISAM3 and EDB
1.08. >>

The best bet would be a simple BLOB column type in ElevateDB (there's only
two BLOB types in EDB, CLOB and BLOB - the graphic type is gone), and make
sure that the BLOB block size for the table is set to 2k or higher.  Your
problem is most likely due to too small of a block size, resulting in a very
large amount of overhead per BLOB block compared to the source data size
that is being stored.

Always remember - the higher the BLOB block size (within reason), the faster
the access will be.  However, it will also result in more slack space being
introduced, so you have to balance things a bit.

Also, ElevateDB has a much more optimal BLOB re-use strategy that does not
cause the amount of fragmentation in the BLOB file that DBISAM did.  In
almost all cases, EDB can read most of the BLOB in one big chunk, even after
many deletions and insertions.

Here's some code from DBISAM that calculates the average BLOB size for a
table (it will work with EDB also):

procedure TForm1.Button1Click(Sender: TObject);
var
  TempNumBlobs: Integer;
  TempBlobSize: Integer;
  TempHighestBlobSize: Integer;
  TempTotalBlobSize: Integer;
begin
  with DBISAMTable1 do
     begin
     First;
     TempNumBlobs:=0;
     TempHighestBlobSize:=0;
     TempTotalBlobSize:=0;
     while (not EOF) do
        begin
        TempBlobSize:=TBlobField(FieldByName('Text')).BlobSize;
        if (TempBlobSize > 0) then
           begin
           TempHighestBlobSize:=Max(TempHighestBlobSize,TempBlobSize);
           Inc(TempNumBlobs);
           Inc(TempTotalBlobSize,TempBlobSize);
           end;
        Next;
        end;
     ShowMessage('Average BLOB size is '+IntToStr(TempTotalBlobSize div
TempNumBlobs));
     ShowMessage('Largest BLOB size is '+IntToStr(TempHighestBlobSize));
     end;
end;

What you do is use these numbers to determine the optimal BLOB block size.
For example, if the average BLOB size is 28k, then an good BLOB block size
would be 4k, resulting in an average of 7 blocks needing to be read.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<What you do is use these numbers to determine the optimal BLOB block size.
For example, if the average BLOB size is 28k, then an good BLOB block size
would be 4k, resulting in an average of 7 blocks needing to be read.>>


Thanks that did help a little.

We are storing thousands of compressed PDF files in our tables.  I am
concerned only with file size.  The speed of opening one PDF at a time is
not an issue.  I assume I should use the smallest block size possible to get
the smallest physical file size.  Is this correct?

Keith,

<< We are storing thousands of compressed PDF files in our tables.  I am
concerned only with file size.  The speed of opening one PDF at a time is
not an issue.  I assume I should use the smallest block size possible to get
the smallest physical file size.  Is this correct?  >>

Well, I wouldn't go too far in terms of using a small block size.  What is
the average size of the PDF file that you will be storing ?

--
Tim Young
Elevate Software
www.elevatesoft.com