Where should I store photos? File system or the database? [duplicate]

Question

Possible Duplicate:
storing uploaded photos and documents - filesystem vs database blob

I am starting to develop a web app, the primary purpose of which is to display photos. The users will be able to upload photos as well.

The first question that came up was where to store the photos: on the file system or the database.

I will be using a Windows box to host the site. The database is MySQL and the backend code is in C# utilizing ASP.NET MVC.

Answer 1

Filesystem, of course, unless you're aiming for a story on thedailywtf. The easiest way is to have the photos organized by a property you can derive from the file itself, such as its SHA-1 hash. Then just store the hash in the database, attached to the photo's primary key and other attributes (who uploaded it, upload date, etc).

It's also a good idea to divvy up the photos on the filesystem, so you don't end up with millions of files in a single directory. So you'll have something like this:

storage/00/e4/f56c0de1c61fdb926e79e8a0a65bd12930c9.jpg
storage/25/9a/ec1c55bfb660548a6770238668c4b117d92f.jpg
storage/5d/d5/4b01d98f17a9ad9dd1526b49ba39b5aa37a1.jpg
storage/63/49/6f740b6c284ce6685dc17d473a7360ace249.jpg
storage/b1/75/066d178188dde110149a8422ab651b0ee615.jpg
storage/b1/20/a2b7d02b7b0c43530677ab06235382a37e20.jpg
storage/da/39/a3ee5e6b4b0d3255bfef95601890afd80709.jpg

This is also easy to port if you ever move to sharded storage.

Answer 2

If you are using SQL Server 2008 there's a Filestream datatype that handles most of the problems mentioned about the DB getting larger. It handles all the annoying details of synchronizing between the filesystem and the table.

Look here for a blog post about the topic: Store any data in SQL Server 2008 (Katmai)