Subject | Re: Database for images |
---|---|
Author | Adam |
Post date | 2007-05-06T23:35:11Z |
--- In firebird-support@yahoogroups.com, Aage Johansen <aagjohan@...>
wrote:
compressed TIFF.
strike? (Maybe Helen or Ann may know)
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.
Adam
wrote:
>10GB a year.
>
> 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
> A reason for moving from files to a database is to improve accesscontrol.
> The images are "compressed TIFF" - I'll try to do some additionalthey are.
> compression, but without significant benefit I will keep them as
> The size of the images varies: 50-500KB.I don't imagine you will be able to significantly compress a
compressed TIFF.
>350GB is quite large. Is there any internal limitations you may
> Any warnings?
strike? (Maybe Helen or Ann may know)
> Currently using Fb/1.5.4If 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.
Adam