My comment about stark raving madmen was somewhat tongue-in-cheek.
There is certainly a case to be made for images in a database under some
circumstances. However, for the average Joe web developer, and
certainly someone new to the whole problem, I think storing them on the
filesystem is going to be by far the most painless and efficient approach.
James Neff wrote:
> "... and Moses said unto them, 'The eleventh commandment : thou shalt
> store images in a database!'..."
>
> What if you had another database where you stored just the images and
> not back it up if you don't want to?
>
> As an application developer, I like the idea of storing files and
> images in the database because it makes it much easier to control
> access and security from an application standpoint.
>
> I think Microsoft SQL Server stores blobs in a separate file, and only
> retains pointers in the actually database field for that blob. So
> when you SELECT on that blob MS SQL reads the external file for you as
> if it lived in the database. I don't know if Postgres does the same
> thing, but if it did, you wouldn't have to worry about "bloating"
> database files.
>
> Sounds like this is for an Apache web application. Think about how
> web sites like Flickr and Webshots store their images in a database.
> You could write a cool Apache mod so that the url:
> "http://mycompany.com/images/01234.jpg" would go through this module,
> pull the appropriate image from the database and send it back; all the
> while the client is none-the-wiser. Just a thought.
>
> I think its one of those things where there's not right or wrong
> answer. Instead you just have to do the minimum of what your
> application requires. If you don't need application-level control
> over the files, then by all means store them on the file system. But
> if you need to control security than you have to prevent physical
> access to the file (which means no file system storage) and pull the
> image from the database through the application.
>
> My two cents,
> James
