> Our number of images is much smaller, but we basically ran into the same
> filesystem limitations as you did. Once we hit around 2,000-3,000 files
> in a single directory it would take a long time to access it. Our
> largest image db is a little over 80 GB and stores around 400,000 images
> (tiff and pdf). So far it has worked quite well and gives us a lot of
> control over access and user rights and that kind of thing without going
> to our network admins.
>
> -steve

If you use IBO, there is a nice little component which zips blob contents on
the fly before inserting/updating and unzips on select.

>
> On Wed, 2005-07-27 at 10:31 +0200, Ivan Prenosil wrote:
>
> > > Background:
> > > I have been reading a lot of posts on whether or not to store image
> > > files in blobs. From what I've read the major issue with this is
> > that
> > > queries can be/are slowed by the blob. The common way to handle
> > > images
> > > is to store the image in the file system and a reference to it in a
> > > column. This works in most cases, but in this particular case I
> > have
> > > such a high volume of images that filesystem limitations come into
> > > play.
> > >
> > > Image description: 2-page tiff aprox. size 24k
> > > Current image count: 25,550,000
> > > Daily addition: 7,000 +-
> > >
> > > Questions:
> > >
> > > 1. If the image files/blobs were stored separate from the data in
> > > their
> > > own table, would there be an impact on overall database performance?
> >
> > If the blobs are larger than db page size, then they will be stored
> > on separate pages anyway, so there is no point in creating another
> > table.
> >
> > >
> > > 2. Can Firebird handle this volume of data?
> >
> > Can't say, my biggest database with pictures in blobs was 70GB,
> > and it worked without problems.
> >
> > Ivan
> > http://www.volny.cz/iprenosil/interbase/
> >