Should I store my images in the database or folders? [duplicate]

Question

Possible Duplicate:
Storing Images in DB - Yea or Nay?

Hi

At the moment each Company on my website have 1 picture they can add to their profile. I save that image into the database....its their Company Logo.

Now i want to allow them to add more pictures. Now i don’t know if i must save it all in the database or save it in folders????

Reason why i think folders will be better is because there are so much nice articles with fancy silver light kinda features that i can use but all of them only cater for images saved in folders.

And since i am not THAT good its hard for me to change the code to look at the database instead of the examples that uses folders for image retrieval.

I would like to add something like this to my website (browsing through the images). Any code examples for me on how to do this when images are saved in the database? I am using ASP.NET with VB.net. Click here to view what i am talking about

Any ideas guys?

Regards Etienne

Callosity

Answer 1

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

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

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

Here is an example

Armadillo

Answer 2

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

Charqui

What do you mean by "secure" as regards storing them in the DB? – Awildaawkward

Assuming that your DB is secured effectively, it provides an extra layer. Attacker needs to identify images are stored in SQL, identify server, username/password, table. Simply scanning a file system on a compromised machine won't yield results and a badly written web site won't expose files through HTTP request techniques (eg leaving files downloadable). Works even better if the SQL Server is on a seperate machine/network. – Charqui

Answer 3

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

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

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

Sickle

If they're created dynamically, why store them at all? – Wernsman

for reuse - it's a hell of a lot cheaper to use an extant image than create the same one every time – Sickle

Answer 4

Two thoughts on this:

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

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

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

Pediatrics

Answer 5

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

---

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

Uel

Answer 6

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

Oscillator

Answer 7

I will go for both.

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

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

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

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

Note, you may want 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.

Tribute

Answer 8

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

Hersey

Answer 9

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

Separate things my friend, best regards!

Reverberator

Answer 10

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

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

Wernsman