in reply to Keep your files in the database!
in thread compressing text

And the reason not to put files in the database is that all of your file-based utilities (rsync, ,tar, less, grep, mv, vim, etc.) become useless and have to be replaced.

I think of it like this: the files are the master data, and the database info about them is just a handy index for locating them based on particular attributes. You can delete the index and rebuild it any time, since the master info is really the files themselves.

Replies are listed 'Best First'.
Re: Re: Keep your files in the database!
by Anonymous Monk on Apr 11, 2003 at 19:16 UTC
    Well you might be using a OS that doesn't have useful file-based tools.
Re: Re: Keep your files in the database!
by Improv (Pilgrim) on Apr 11, 2003 at 19:36 UTC
    Remember that with many of those tools, you'll need to update the database afterwards anyhow, and that's not necessarily a trivial thing to do after arbitrary changes to the directory. Really though, you do have a point that, depending on needs, it's not entirely unreasonable to prefer the filesystem to be the primary data store. I personally strongly prefer the integrity constraints possible when the database manages everything, but I can see how people might have different needs. With changes to the files mentioned, I wouldn't use mv (psql can rename the blobs), and for the rest, I'd pull them out of the database, change them, and insert (update?) them back in. *shrug*