And I'd like to add this: storing files outside the database and linking them from the database via
a filename is a true pain.

I do that for my website, and the code to handle update/insert/delete of those "files" is nasty. I
write the file to disk first, and abort the transaction manually if something goes wrong there. If
the transaction aborts for reasons of its own, then I have to undo my on-disk changes to the file.
So my "delete" involves copying a file to a new location, so I can copy it back in case of a
problem, deleting the file (if the copy went well), deleting from the database, then deleting the
temporary file, assuming the transaction committed. If not, then I copy the file back, and delete
the temporary copy if that worked.

However, I could still have problems:
- I could be unable to copy the temporary file back (don't ask why, it's simply possible),
- files could be deleted or modified without appropriate changes to the database,
- changes to the database might happen without changes to the file system,
- I might not be able to delete the temporary copy, leaving temporary files strewn about ...

(There are likely more things that can go wrong than I can think of, sadly.)

Maintaining transaction consistency by hand isn't just a pain, it's also not exactly possible. You
really want the security you get from having a single authority (the db server) deciding if things
have succeeded or not. Although BLOB-handling might be a pain in some languages (or via certain
API's), it's worth the peace of mind you get from it.

Also, because of my (stupid) use of file storage, security is no longer guaranteed. You can access
hidden articles and images from my website even if I've made the database entry unavailable to
guests. It was somewhat done on purpose: I wanted images to appear on pages directly, without a
call to some php or cgi code to pull the image from the database on-demand. For me, it's not really
a problem. The stuff is meant to be public, and I know better than to upload sensitive information
to my own website. However, for some people, that's likely not enough in the way of security.
Separate files mean separate access paths, and the possibility of losing control. A wall isn't much
security if you leave the door open.

-Philip

---------- Original Message -----------
From: "Ann W. Harrison" <aharrison@...>

>
> The usual reason for storing images outside the database is sheer database
> size which affects the ability to backup and restore the database.
>
> Regards,
>
> Ann
> www.ibphoenix.com
> We have answers.

------- End of Original Message -------