| Subject | Re: [firebird-support] big images in database |
|---|---|
| Author | Lester Caine |
| Post date | 2009-07-19T08:15:38Z |
Dimitry Sibiryakov wrote:
to the half way house of having the 'storage' database separate to the main
database so that it could be run on a separate machine. This gives some
apparent advantages, but I'm now back to keeping the data relating to the
files ( meta data from pictures or text transcript of PDF files ) along with
the main database, but files in a simple 'numeric' directory structure. This
can store the relevant thumbnails and other related documents in one place and
I just need the number to access them - and can clone the storage structure to
multiple machines if needs be. The document/image number simply translates to
a directory path and keeping things in sync is easy - at least that is what
I'm now finding.
I've just been adding 'music' to my local archive, and each directory has a
set of tracks for the CD, images of the artwork, and thumbnails (in various
sizes) to display. It is working a lot easier than having each track and image
as separate 'files' in the original structure! And an rsync each night
duplicates everything added during the day ... although if this gets added to
my customer systems, then the files would be stored in two places.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
>> why overload your administration task (think of backups!) by storing objects that won't change? Consider also the extra overhead in the cache and across the network in possibly retrieving large blobs that your users normally would need to have at the client only on request, e.g. via a Show/Select image button.Having been through the phase of putting everything in the database, I moved
>
> For the sake of consistency, for example. Keeping files in FS and
> references in DB in synch is a nightmare.
> Overhead level depends only on radius of curvature of application
> coder's hands.
to the half way house of having the 'storage' database separate to the main
database so that it could be run on a separate machine. This gives some
apparent advantages, but I'm now back to keeping the data relating to the
files ( meta data from pictures or text transcript of PDF files ) along with
the main database, but files in a simple 'numeric' directory structure. This
can store the relevant thumbnails and other related documents in one place and
I just need the number to access them - and can clone the storage structure to
multiple machines if needs be. The document/image number simply translates to
a directory path and keeping things in sync is easy - at least that is what
I'm now finding.
I've just been adding 'music' to my local archive, and each directory has a
set of tracks for the CD, images of the artwork, and thumbnails (in various
sizes) to display. It is working a lot easier than having each track and image
as separate 'files' in the original structure! And an rsync each night
duplicates everything added during the day ... although if this gets added to
my customer systems, then the files would be stored in two places.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php