Images in database vs file system

Question

We have a project coming up where we will be building a whole backend CMS system that will power our entire extranet and intranet with one package. The question I have been

Answer 1

I would not store images in the database for one reason (my answer comes from sql server):

I would not want SQL Servers Data Cache Populated by simple images for the web site. I want the data cache to actually have data in it. Also if you have a multi-tiered architecture its much easier to pass a URL for an image than a blob of binary data. Where you do run into issues though if you only want certain people to see the images (security).

Answer 2

I would;

1) Assign unique identifier (GUID) to each image 2) Tag/Name the image with that GUID 3) Store GUID in the OS (File System) 4) Store Fully Qualified File Name (FQN) pointer in the database.

Storing images in the database is too expensive in terms of storage and maintenance. Storing just the FQN pointer would provide better solution. You can also build back-end integrity check through triggers and some stored procedures.

Answer 3

There was a nice research paper published by Microsoft Research called To Blob or not to Blob where they looked at all sorts of variables and impacts.

Their finding in the end:

• up to 256 KB in size, blobs are stored in the database more efficiently than in the file system
• for 1 MB and larger, the file system is more efficient
• in between it's a toss-up

Since that paper was published, SQL Server 2008 has also added the FILESTREAM attribute which makes storing stuff in the file system, but under transactional control, a reality. Highly recommended you check that out!

Answer 4

This question comes up often - see this SO search result.

There is no one right answer - it depends on circumstances.

Personally - keep a file path in the DB and the file on the filesystem. Each has its own strengths. You can backup files as well as databases. This is also the conclusion of this guy, who manages TBs of data.