12-26-2011, 06:47 PM
I ran across an article today about how to store images in a database. I found it fascinating, and a very simple method of storing images that are uploaded.
I am wondering, as long as I do the proper sanity checks when inserting, what the pros/cons of images in a database are? Is this method used on professional sites? In what context? I'm guessing its not for stuff like backgrounds or design elements, as I take these images wouldn't be stored as temporary files?
12-26-2011, 08:48 PM
As far as I know from my small experience (though do remember that quality of pros/cons should outweigh the quantity):
- Files are saved "forever"
- Can restrict access to the real file more easily
- You can, technically, check for duplicate files.
- You are not keeping the files on drive, so it can be faster to access for the server
- Less files on your server is considered "better" and more organized
- "one file for everything"
- If site is up but database is not, file will be invalid (through "direct" linking)
- Some databases that cannot be reconfigured only allow blobs to be of a certain size limit (a few mb), therefore making it so that really large images cannot be stored (but can be separated)
- More data becomes stored in memory when loading file to (to a variable); similar to the problem above, very large images can slow down your server.
- Some files may be of different character encoding, and thus storing and/or retrieving files may corrupt the original file. I am not sure if this is real problem, but I think it was.
I personally do not store files on my database anymore because of the cons.
12-26-2011, 10:14 PM
So far, I've only been considering using it for profile images, as I couldn't think of these its really applicable. But I've heard it discussed before and I don't yet see how its used in a professional site.
I have some ideas mind you... I recently made a site for a used car dealership, and they wanted the ability to upload multiple images of the vehicle. So I set it up that when the vehicle dataset was created, a folder was made under the ID in a folder for the images, and any uploaded images were moved there. It was a bit of a messy system. Having them upload to a DB would have been cleaner.
Any thoughts to other possible uses? Or is it really just an obscure technique, not oft used?
12-26-2011, 10:35 PM
I don't think it's obscure; its uses are as I have described in the Pros. It really just depends on how you want to store files. More over I don't think it's exactly correct to say that storing files in a database is cleaner because if you have a proper data structure to store file information and files, it can be just as clean (if not cleaner). Of course that does require more coding, and as a programmer myself I find it trivial to write more code when there is something already out there for me to use.
I cannot come up with many ideas of the uses of this, as my interaction with it was generally with file management systems. So if it has anything to do with managing files, storing files in a database can apply.
12-27-2011, 01:19 AM
One *HUGE* PRO for images in the DB: In a truly large system, the DB might be distributed across many servers. Or in even a fair-sized system that needs 100% up-time the DB might be replicated across multiple servers. With the images in the DB, then images are also distributed and/or replicated. You *can* set up file replication, but it's generally less well-supported than DB replication/distribution.
But if you are on a relatively small system, especially one where the DB server and the Web server are on the same machine, I don't see any pro's worth considering, really.
12-29-2011, 01:49 PM
Pros. If images are stored as files it may cause you problems with server backups and overall server speed. For example when you try to archive files from control panel web gui or run a backup process, this operation will take longer time and most likely crash.
Therefore most of shared hosting plans have restrictions on the number of files that can be stored under an account.
12-29-2011, 05:46 PM
Ah, ok, so probably not something I'm too interested in right now, but for larger projects, its a viable if not preferable alternate.