[ACCEPTED]-Should I store my images in the database or folders?-file

I've done it both ways recently and personally; I 16 do prefer using the directory method for 15 storing the images while keeping their properties 14 in a DB.

Main reason: I had client to whom 13 I made a website for. On the Webiste; there 12 was a Photo Gallery section that allowed 11 the user to upload new photos (which could 10 be browsed from the public site). Since 9 my client hasn´t thought on optimizing the 8 images before uploading; the *.jpg was over 7 1mb. I did implement the ability to update 6 the image (once it was saved to the DB) but 5 it had to be done one record at a time.

If 4 this happens while storing the images in 3 a directory, then the files can be saved 2 locally, optimized and put back onto the 1 server.

Here is an example

I'd go for folders. More flexibility if 4 you run out of sttorage space (just move 3 them to another disk and re-point), more 2 flexibility with other apps (eg. Silverlight). I'd 1 only use DB for files that had to be secure.

For any normal site you absolutely want 17 this as part of the site app itself, not 16 stored in a DB. A web site should as much 15 as possible be self contained to keep it 14 portable, and not adding round trips to 13 the DB (even where caching) can only be 12 a good thing. Web servers are very good at serving 11 image files.

However, I personally am working 10 on an app where the images are dynamically 9 created and made available to the site through 8 a second management application. Clearly 7 these must be DB backed in some form to 6 keep the images maintainable and secure.

Long 5 story short, where the images have business 4 value (i.e. they're content, they need security, or 3 they're dynamic) you're going to have to 2 store them in a DB. Where they're static 1 and trivial let the website be a website.

Two thoughts on this:

1. Use the filesystem. But 19 make sure you design your scheme well enough 18 that any one folder is not overloaded with 17 images and it becomes something of a nightmare 16 to manage. For instance, you can tree it 15 out with first or last letters of the identifier, or 14 subsequent positional notation. Your mileage 13 will vary, so make sure the scheme fits 12 your data set (images) size. No need to 11 go to detailed lengths if you're only managing, say, 20 10 images.

2. Use SQL Server 2008. It has a new 9 datatype called filestream while will save 8 the images to the filesystem but allow you 7 to retrieve it via standard database queries. See 6 http://msdn.microsoft.com/en-us/library/cc949109.aspx for more information.

These aren't exclusive 5 choices, but at the very least, I'd recommend 4 option #1 for the sheer fact that you'll 3 get better performance out of using a filesystem-based-scheme 2 rather than storing and reading blobs out 1 of a database.

I think saving images in system folders 10 is the best way.
working with DB and Queries 9 you know will cause some overloads and DB 8 transanctions usually are heavy and it 7 can place more stress on your server.
with 6 the way u save images in folders and just 5 put URLs in DB it is more suitable for your 4 app loads.
but the advantage of DB is that 3 you can BackUp your images.

My Suggestion: save 2 your Images in folders. the only need is 1 to know about system I/O operations.

The approach I generaly use is to copy images 6 to a folder and keep the relative URLs in 5 the database. The downside to this approach 4 is that if someone deleted the images you 3 end up with "image not found" in your web 2 pages unless you check everytime you render 1 a page.

I will go for both.

Firstly, store every 13 image as a BLOB column in database. By doing 12 so, you can be rest assured that the image 11 is always included in your database backup 10 (assuming you do it).

Secondly, copy the 9 file into folder. By doing so, you can avoid 8 from query the database (for the image file) every 7 time. Storing in folder alone may have implications 6 such as

• file lost due to disk corrupted
• file are not included in backup operation

So far all of our customer projects 5 are taking the same approach and we have 4 encountered various problems, but no uploaded 3 files are lost. (We are talking about >100GB 2 of uploaded documents).

Note, you may want 1 to look at the following:

1. Ensure that whenever the file is updated / replace, do it on both database and folder. Otherwise, it will be inconsistent.
2. You may want to have a separate table to store the file's info. Typically you may want to store the following: (1)file name (2)file type (3)file size / mime type
3. You may want to split the tables that store data. Our practice is once the table reaches 2GB, we create another table. Designed properly, there shouldn't any problem in finding the right table.

Hope this helps.

AFAIK, flickr.com goes with folders/file 2 server as well with the reference,metadata,etc 1 stored in db. See flickr architecture

I had the same question for my site too. I've 7 decided to use the folder implementation, because 6 if you use the database, when you want to 5 backup only the pics you shoul backup the 4 whole database... on the other hand you 3 can keep de directory structure, and make 2 an easy backup.

Separate things my friend, best 1 regards!

The advantage of using folders is that you 10 don't need to have a custom handler that 9 fetches those BLOBs out of a database and 8 turns them into regular streams. It's also 7 simpler to host them from different locations 6 and you'll avoid the burden on the database 5 server.

You have to be careful about storing 4 the pathnames. Relative pathnames work better 3 as URLs and will allow you some flexibility 2 and scaling in where you store them, how 1 you serve them, and so forth.