On Feb 25, 2007, at 9:26 AM, Tomas Vondra wrote:
Store the pictures in the filesystem and only the path,
description and
other metadata in the database. My suggestion ;-)
Andreas
Don't do that - the filesystems are not transactional (at least not
the usual ones), so you'll lose the ability to use transactions.
Imagine what happens when you do an unlink() and then the
transaction fails for some reason - there's no way to 'rollback'
the filesystem operation. I've seen this solution (storing images
in filesystem) mostly in MySQL applications, but that's because of
(a) lack of transactions in MySQL and (b) somehow sub-optimal
handling of binary data as MySQL loads all the data even if it's
not needed (this was true for MySQL 3.23 - I'm not sure about the
current releases).
You just need to implement it correctly. I've done this by using an
in-database delete queue that's polled by an external process to
delete the image files.
For external image files you don't need to be perfectly
transactional, as long as the failure mode is occasionally leaving a
file in place when it shouldn't be, as all that does is leak a little
filesystem space which can easily be recovered by a periodic task.
Anyway, I do recommend storing images in the database, using a
'bytea' column for the binary data (and load them only if reallly
needed, using proper projection). You can do some benchmarks, but
I've never head performance problems with it on PostgreSQL and the
ability to use transactions was invaluable (it saved us hundreds of
hours when the machine went down for some reason).
The overhead of serving images from postgresql is much higher than
serving them directly from the filesystem (as is the overhead of
backing the data up). For simple, static images the advantages of
full transaction support on the data as well as the metadata are
likely to be fairly minimal.
Both approaches work, which is going to be better will depend on the
details of what you're doing with the images and how far you want it
to scale. (But I can't think of any case where *my* preferred
approach would be to keep them in the DB).
Cheers,
Steve
