PHP to store images in MySQL or not?

Question

I have built a small web application in PHP where users must first log in. Once they have logged in, I intend on showing a small thumbnail as part of their \"profile\".

Answer 1

Always depends of context, but usually, I store a user image on the filesystem in a folder called /content/user/{user_id}.jpg and try to bother the database as little as possible.

Answer 2

These are the pros of both solutions

In BLOBS :

1) pros : the easiness to mange clusters since you do not have to handle tricky points like file syncs between servers

2) DB backups will be exhaustive also

In files

1) Native caching handly (and that's the missing point of previous comments, with refresh and headers that you won't have to redesign in DB (DB are not handling last modification time by default)

2) Easiness of resizing later on

3) Easiness of moderation (just go through your folders to check if everything is correct)

For all these reasons and since the two pros of databases are easier to replicate on file system I strongly recommend files !

Answer 3

After researching for days, I made a system storing images and binaries on the database.

It was just great. I have now 100% control over the files, like access control, image sizing (I don't scale the images dynamically, of course), statistics, backup and maintenance.

In my speed tests, the sistem is now 10x slower. However, it's still not in production and I will implement system cache and other optimizations.

Check this real example, still in development, on a SHARED host, using a MVC: http://www.gt8.com.br/salaodocalcado/calcados/meia-pata/

In this example, if a user is logged, he can see different images. All products images and others binaries are in DB, not cached, not in FS.

I have made some tests in a dedicated server and results were so far beyond the expectations.

So, in my personal opinion, although it needs a major effort to achieve it, storing images in DB is worth and the benefits are worth much more the cons.

Answer 4

I think that most database engines are so advanced already that storing BLOB's of data does not produce any disadvantages (bloated db etc). One advantage is that you don't have any broken links when the image is in the database already. That being said, I have myself always done so that I store the file on disk and give the URI to the database. It depends on the usage. It may be easier to handle img-in-db if the page is very dynamic and changes often - no namespace -problems. I have to say that it ends down to what you prefer.

Answer 5

Just tested my img's as blob, so. This solution working slower than images on server as file. Loading time should be same with images from DB or http but is't. Why? Im sure, when images are files on server, browser can caching it and loading only once, first time. When image going form DB, every time is loaded again. That's my oppinion. Maybe Im wrong about browser caching, but working slower (blob). Sry my English, whatever ;P

Answer 6

Challenging the Conventional Wisdom!

Of course it is context dependent, but I have a very large application with thousands of images and documents stored as BLOBS in a MySQL database (average size=2MB) and the application runs fine on a server with 256MB of memory. The secret is correct database structure. Always keep two separate tables, one of which stores the basic information about the file, and the other table should just contain the blob plus a primary key for accessing it. All basic queries will be run against the details table, and the other table is only access when the file is actually needed, and it is accessed using an indexed key so performance is extremely good.

The advantages of storing files in the database are multiple:

1. Much easier backup systems are required, as you do not need to back up the file system
2. Controlling file security is much easier as you can validate before releasing the binary (yes, you can store the file in a non-public directory and have a script read and regurgitate the file, but performance will not be noticeably faster.
3. (Similar to #1) It cleanly separates "user content" and "system content", making migrations and cloning easier.
4. Easier to manage files, track/store version changes, etc, as you need fewer script modifications to add version controls in.

If performance is a big issue and security and backups aren't (or if you have a good fs backup system) then you can store it the the FS, but even then I often store files (in the case of images) in the DB and building a caching script that writes the image to a cache folder after the first time it's used (yes, this uses more HD space, but that is almost never a limiting factor).

Anyway, obviously FS works well in many instances, but I personally find DB management much easier and more flexible, and if written well the performance penalties are extremely small.