James Smith wrote:
There are good reasons to store images (especially small ones) in
databases (and with careful management of headers in your mod_perl).
Some of you have missed inherent problems with the file systems
even balanced heirarchical tree - ones in a shared server
environment which can lead to gross efficiencies - in your cases
you may not be doing multiple deletes - but in the examples I work
with it is not the creation and storage which breaks the file
system, but the requirement to clear our old files before filling
up the file system.
Finally, someone who does not agree with the general line.
That makes it more interesting.
As for the size, the OP indicated that his objects were pictures (photos
I believe), which tend to be in the multi-MB range, and growing as
cameras get more pixels. The documents we handle also, since there is a
notable tendency to inflation of office document sizes, what with
embedded pictures and graphics and such.
I guess indeed it also depends on whether the stored images/documents
are transient, or stay forever. In our case they stay forever, because
they are part of a kind of archive. Once loaded, a document is never
deleted.
That is why we do not just store the original documents in a purely
hierarchical file structure, but have developed a system based on a
notion of "logical volumes", which can be moved without affecting the
link between the database records and the stored objects.
This being said, the organisation in question is still on top of
classical filesystems.
In recent years, the universal support under Unix/Linux of "LVM's" much
simplifies the question of space management, physical location etc.
Disk storage per volume unit is also getting ever larger and cheaper, so
it does not cause us big concern.
At the limit, if a certain document collection is not needed anymore,
the corresponding records can be moved to an archive table or database,
but the documents themselves stay.
