Should images be stored in a database

In those cases, you can store images directly in the database and then load them using application code. Navicat development and administration tools provide excellent support for image management.

In today's blog, we'll learn how Navicat makes storing images a simple process. For the purposes of demonstration, I'll be using Navicat Premium against a MySQL 8 database, but the same procedure would apply to other relational databases as well. However, there are actually three flavors of BLOB. Most of the time, it will make more sense to have the images stored in the file system, but you should be aware of situations where it may be advantageous to store them in a database.

Next, add an Image element from the palette to the band in the report design and then modify the the Image Expression class to java. Image thus matching the field type , and set the Image expression to the field holding your image. Choose the MySQL or Postgres scripts, which will create a sample table in the database and store the images in the database. Smaller sized files can be efficiently stored and delivered using the database as the storage mechanism.

Here's an additional point to keep in mind. One of the reasons supporting the use of a database to store the blobs is ACID compliance. One thing that I haven't seen anyone mention yet but is definitely worth noting is that there are issues associated with storing large amounts of images in most filesystems too.

For example if you take the approach mentioned above and name each image file after the primary key, on most filesystems you will run into issues if you try to put all of the images in one big directory once you reach a very large number of images e. Something nobody has mentioned is that the DB guarantees atomic actions, transactional integrity and deals with concurrency. Even referentially integrity is out of the window with a filesystem - so how do you know your file names are really still correct?

If you have your images in a file-system and someone is reading the file as you're writing a new version or even deleting the file - what happens? We use blobs because they're easier to manage backup, replication, transfer too. They work well for us. The problem with storing only filepaths to images in a database is that the database's integrity can no longer be forced. If the actual image pointed to by the filepath becomes unavailable, the database unwittingly has an integrity error.

Given that the images are the actual data being sought after, and that they can be managed easier the images won't suddenly disappear in one integrated database rather than having to interface with some kind of filesystem if the filesystem is independently accessed, the images MIGHT suddenly "disappear" , I'd go for storing them directly as a BLOB or such. At a company where I used to work we stored million images in an Oracle 8i then 9i database. Normally, I'm storngly against taking the most expensive and hardest to scale part of your infrastructure the database and putting all load into it.

On the other hand: It greatly simplifies backup strategy, especially when you have multiple web servers and need to somehow keep the data synchronized. We have implemented a document imaging system that stores all it's images in SQL blob fields. There are several hundred GB at the moment and we are seeing excellent response times and little or no performance degradation.

In addition, fr regulatory compliance, we have a middleware layer that archives newly posted documents to an optical jukebox system which exposes them as a standard NTFS file system. If this is web-based application then there could be advantages to storing the images on a third-party storage delivery network, such as Amazon's S3 or the Nirvanix platform. I'm surprised no one has really mentioned this Another StackOverflow threads talking about this here.

This thread explains why you should use a 3rd party hosting provider. It's so worth it. They store it efficiently. No bandwith getting uploaded from your servers to client requests, etc. If you're not on SQL Server and you have some solid reasons for putting specific image files in the database, then you could take the "both" approach and use the file system as a temporary cache and use the database as the master repository.

For example, your business logic can check if an image file exists on disc before serving it up, retrieving from the database when necessary. This buys you the capability of multiple web servers and fewer sync issues. I'm not sure how much of a "real world" example this is, but I currently have an application out there that stores details for a trading card game, including the images for the cards.

Granted the record count for the database is only records to date, but given the fact that certain cards have are released multiple times and have alternate artwork, it was actually more efficient sizewise to scan the "primary square" of the artwork and then dynamically generate the border and miscellaneous effects for the card when requested. The original creator of this image library created a data access class that renders the image based on the request, and it does it quite fast for viewing and individual card.

This currently sizes up to 56MB, which isn't great, but I'm working on an incremental update feature for future releases. In addition, there is a "no images" version of the application that allows those over dial-up to get the application without the download delay. This solution has worked great to date since the application itself is targeted as a single instance on the desktop.

There is a web site where all of this data is archived for online access, but I would in no way use the same solution for this. I agree the file access would be preferable because it would scale better to the frequency and volume of requests being made for the images.

SQL Server offers a solution that has the best of both worlds : The filestream data type. It depends on the number of images you are going to store and also their sizes. I have used databases to store images in the past and my experience has been fairly good.

You don't need FS structure to hold your images B. Database indexes perform better than FS trees when more number of items are to be stored C.

Smartly tuned database perform good job at caching the query results D. Backups are simple. It also works well if you have replication set up and content is delivered from a server near to user. In such cases, explicit synchronization is not required.

Storing images may be a bad idea when you are dealing with small number of huge sized images. Another problem with storing images in db is that, metadata like creation, modification dates must handled by your application. I'd call my implementation a success, it takes care of backup requirements and simplifies the layout of the project. The performance is fine for the people who use the app.

Im my experience I had to manage both situations: images stored in database and images on the file system with path stored in db.

The first solution, images in database, is somewhat "cleaner" as your data access layer will have to deal only with database objects; but this is good only when you have to deal with low numbers. Obviously database access performance when you deal with binary large objects is degrading, and the database dimensions will grow a lot, causing again performance loss The only advantage to this approach is that you can better secure your images because you can use the database security features.

An alternative, and better method is to store the images outside of the database and store only a link to the image file. You only need a text field in your database table to store this information.

The only problem to this approach is that you must synchronize the data in the link field with your file system.