Pro & Cons of storing files(pictures) in a SQL Server for a website

Question

I\'m creating an Asp.Net MVC website.

I\'ve in the past, for heavy application, multiple layer application, used the database to store files.

But now I\'m questi

Answer 1

There's a really good paper by Microsoft Research called To Blob or Not To Blob.

Their conclusion after a large number of performance tests and analysis is this:

• if your pictures or document are typically below 256K in size, storing them in a database VARBINARY column is more efficient

• if your pictures or document are typically over 1 MB in size, storing them in the filesystem is more efficient (and with SQL Server 2008's FILESTREAM attribute, they're still under transactional control and part of the database)

• in between those two, it's a bit of a toss-up depending on your use

If you decide to put your pictures into a SQL Server table, I would strongly recommend using a separate table for storing those pictures - do not store the employee foto in the employee table - keep them in a separate table. That way, the Employee table can stay lean and mean and very efficient, assuming you don't always need to select the employee foto, too, as part of your queries.

For filegroups, check out Files and Filegroup Architecture for an intro. Basically, you would either create your database with a separate filegroup for large data structures right from the beginning, or add an additional filegroup later. Let's call it "LARGE_DATA".

Now, whenever you have a new table to create which needs to store VARCHAR(MAX) or VARBINARY(MAX) columns, you can specify this file group for the large data:

 CREATE TABLE dbo.YourTable
     (....... define the fields here ......)
     ON Data                   -- the basic "Data" filegroup for the regular data
     TEXTIMAGE_ON LARGE_DATA   -- the filegroup for large chunks of data

Check out the MSDN intro on filegroups, and play around with it!

Answer 2

Why use db instead of txt files? Because its faster it uses indexes. Storing whole files in db is never a good practice. Use db as index (pointers) to the normal img files.

As far as your pros / cons go:

• you can easily controll if the user has the right to see the image if you display the image with asp / php and set root image folder outside web root

• storing whole files in db is cca 10 times slower (I know for mysql testing but its similar for mssql - http://blog.sitek.com.au/2008/03/comparison-between-storing-imagesfiles-in-mysql-and-on-filesystem/)

• if you have files in db you wont be able to use CDNs (http://en.wikipedia.org/wiki/Content_delivery_network)

Answer 3

If the files are integral and actively changing part of the system and them have to be backed up along with the other data - you can store them inside the DB, but try to use the FILESTREAM fields if you use sql server 2005+ and your files are big enough - say 500k+

If the files are static content, you can store them outside with only pointers in DB. This not prevents to take into account all your custom permissions machine.

Storing and working with files inside DB is usually slower, than in filesystem, but all depends on your needs.