Re: images in database

Shridhar Daithankar wrote:
>
> On Thursday 03 April 2003 17:38, you wrote:
> >
> > In the end, we went with large objects because my tests showed them faster
> > than bytea and there could be large sized objects, a B64 encoding would
> > bloat the size (encode/decode time and size bloat were what slowed the
> > bytea down I think) and the large objects let us extract the file in
> > portions for streaming should we wish.
>
> Just wondering, how does it exactly differ from storing an image in a file and
> storing the filename in the database?

The image data would not be included in a database dump. So you loose
the ability to save a consistent snapshot.

The image data would not be accessible remotely except if made available
via network filesystems. Then you get permission and path problems.

The image data does not follow the same transactional semantics as all
other data. Due to MVCC, some process might actually have a write lock
on the row containing the filename and is right now writing to the file
while another process reads the old row and then the (intermediate mess
in the) file.

Rolling back a database transaction in case of whatever error will not
rollback changes to the image data.

Process (or system) crash in the middle of an update is not covered by
the databases crash recovery capability.

Enough reasons to forget about filename storage?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #