Store user's images in a web application

I have a web application currently being developed in JSP/Servlets.

The application allows users to upload image files for each user account.

What is the 开发者_JS百科best way to store the images?

Please consider the following features that I'd like to have before your answer;

1. I am using MySQL now, but there could be a possibility of moving to a different database.

2. I can store the images as flat files, but I want the admin account to have an option to backup the complete database and reload it later. Ideally the backup/reload should work with the images too. (even if the backup was done from a different physical machine and reload was done from a different machine)

3. Using BLOB/CLOB is an option that solves problem 2.

   But, what if my database becomes very large?

---

In your case, I strongly recommend you having a blob field on your database and store the images in it. Mainly, because this is the correct place for them. So, make a Servlet that retrieves the image of the specified user from the database. For example, /userimage?name=john.

About your "size/performance" problem:

• Databases were made (among other things) to store and exchange large amounts of data.
  So, they're the best option.

• Even if you store them on other sites, they will still reduce free space and performance.

• If you really want to manage LARGE data (>= 3TB, not your case) then you can store them on a file system and save the filenames in the DB. For more info, look at this question.

---

Store them in the file system. It's faster and simpler. Often, when accessing an image, you're going to have to save it to a file anyway before you can utilize it. You can examine the images with third party tools. You can store the recordID in the filename to keep the image/record association from ever being broken.

Many others share this opinion: http://forums.asp.net/p/1512925/3610536.aspx

---

Just store them in the DB... if your user base "becomes very large" you'll have buckets of cash to buy a balls-out database server (or even a farm of them) which can handle the load, now won't you?