Subject Re: Database for images
Author Adam
--- In, Aage Johansen <aagjohan@...>
> I'm contemplating putting all of our images (3+ million, I think)
> into a single database. The table will just hold a PK, some
> identifying items (<16 bytes), and a blob to hold the images. A
> rough estimate gives a size of 350GB, with perhaps an additional
10GB a year.
> A reason for moving from files to a database is to improve access
> The images are "compressed TIFF" - I'll try to do some additional
> compression, but without significant benefit I will keep them as
they are.
> The size of the images varies: 50-500KB.

I don't imagine you will be able to significantly compress a
compressed TIFF.
> Any warnings?

350GB is quite large. Is there any internal limitations you may
strike? (Maybe Helen or Ann may know)

> Currently using Fb/1.5.4

If you take that route, I would seriously look at FB 2. You probably
don't want to be running gbak on a database that size. NBackup can
handle incremental backups, which from your description would seem
more appropriate.

Another possibility would be to store the images in the file system in
an folder that only your firebird and backup process has access to.
The table could then hold only paths. You could write a UDF to accept
a path and return a BLOB containing the image. Write a view that uses
that makes it look like the table you originally envisaged. Your
database is then quite small, takes only minutes to backup, your
images can be backed up using XCopy or [whatever backup tool is
currently in use] and your security is easily managed.