> It would be convenient to have fast access to binary data in
> the database
> that is similar to what other databases do. This would allow more
> applications to run on PostgreSQL.
For small sets of files you're probably right. When you start to reach
millions of files, it makes much more sense to separate things.
I live in an environment where we manage just over 18 million images.
We do the pointer thing and have a completely separate "image farm" to
store the images.
> Not everybody will have the opportunity to access the local
> filesystem, e.g.
> ISPs providing servlet hosting will likely turn of access to
> the filesystem.
This is very true. But if you do have access to the local filesystem,
why not use it? It's far more efficient that executing a query against
the database and forcing the database to chunk in the data.
> It is also more work to write code to manage files in the
> filesystem. Why
> store pointers to the actual files in the database, if I can store the
> files themselves there.
In my mind, databases are for storing things that you want to search.
It makes no sense to search the bytes of an image, but it does make
sense to search the database to find where the image is located.
Plus, if you do the pointer thing and if the pointers are URL's, images
can live anywhere: local fileystem, remote ftp server, remote web
server, remote samba server, whatever.
> As for speed of access you could always provide a cache for the images
> in your application.
true. You'd probably want to do that regardless of where the images are
physically located.
>
> I've done the pointer to filesystem type of implementation in a CMS
> system before and that turned out be messy to manage. E.g. If
> the disk is
> full when adding a image, rollback transaction. What if some
> ignorant user
> messes up the files ? Access control to the images, for that
> we need to go through the application anyway.
If you're managing large systems things are going to be complicated,
whether you're tracking images or chickens. You've got to find the
solution that will give you the most long-term flexibility, even if that
means more complication.
eric
