Web Development – Store Images in Database or Files with Database Link?

Reasons in favor of storing files in the database:

1. ACID consistency including a rollback of an update which is complicated when the files are stored outside the database. This isn't to be glossed over lightly. Having the files and database in sync and able to participate in transactions can be very useful.
2. Files go with the database and cannot be orphaned from it.
3. Backups automatically include the file binaries.

Reason against storing files in the database:

1. The size of a binary file differs amongst databases. On SQL Server, when not using the FILESTREAM object, for example, it is 2 GB. If users need to store files larger (like say a movie), you have to jump through hoops to make that magic happen.
2. Increases the size of the database. One general concept you should take to heart: The level of knowledge required to maintain a database goes up in proportion to the size of the database. I.e., large databases are more complicated to maintain than small databases. Storing the files in the database can make the database much larger. Even if say a daily full backup would have sufficed, with a larger database size, you may no longer be able to do that. You may have to consider putting the files on a different file group (if the database supports that), tweak the backups to separate the backup of the data from the backup of the files etc. None of these things are impossible to learn, but do add complexity to maintenance which means cost to the business. Larger databases also consume more memory as they try to stuff as much data into memory as possible.
3. Portability can be a concern if you use system specific features like SQL Server's FILESTREAM object and need to migrate to a different database system.
4. The code that writes the files to the database can be a problem. One company for whom I consulted not so many moons ago at some point connected a Microsoft Access frontend to their database server and used Access' ability to upload "anything" using its Ole Object control. Later they changed to use a different control which still relied on Ole. Much later someone changed the interface to store the raw binary. Extracting those Ole Object's was a new level of hell. When you store files on the file system, there isn't an additional layer involved to wrap/tweak/alter the source file.
5. It is more complicated to serve up the files to a website. In order to do it with binary columns, you have to write a handler to stream the file binary from the database. You can also do this even if you store file paths but you don't have to do this. Again, adding a handler is not impossible but adds complexity and is another point of failure.
6. You cannot take advantage of cloud storage. Suppose one day you want to store your files in an Amazon S3 bucket. If what you store in the database are file paths, you are afforded the ability to change those to paths at S3. As far as I'm aware, that's not possible in any scenario with any DBMS.

IMO, deeming the storage of files in the database or not as "bad" requires more information about the circumstances and requirements. Are the size and/or number of files always going to be small? Are there no plans to use cloud storage? Will the files be served up on a website or a binary executable like a Windows application?

In general, my experience has found that storing paths is less expensive to the business even accounting for the lack of ACID and the possibility of orphans. However, that does not mean that the internet is not legion with stories of lack of ACID control going wrong with file storage but it does mean that in general that solution is easier to build, understand and maintain.

On file size

You need to deal with the vast array of issues that come from the sheer size of images - whether compressed or not, images range from hundreds of KBs and up - which is tens to hundreds times larger than the typical amount of data your frontend/backend handles per operation.

Therefore, the first strategy is to focus on reducing the image size. Don't bother with techniques that only improve a few percents - to make things improve, you need an order of magnitude better compression.

The best file-size-reduction approach is to scale down the image - as much as you can without making your users angry.

If you use JPEG or WebP (or some other lossy formats) you can try use different quality level. Sometimes the best trade-off is obtained from a combination of scaling down and adjusting quality level. Don't limit your scale-down factors to powers-of-two.

The second best image compression approach depends on the type of image content. You will need to learn about the basics of compressed image formats, and be creative applying those basics.

In one very simple approach, large areas of uniform color is simply cropped away from the image, and replaced with a background color - to be painted by the app - using the same RGB hex.

On versioning

The backend database needs to be able to serve a checksum, timestamp (last modified time) or file version number that serves to inform the app whether they have the most up-to-date file.

On keeping the user from boredom

You might need to show small, fast-to-download thumbnails (which are scaled down versions of the image) just in case your app users are quick-tempered. Make sure these thumbnails are properly cached by the backend - loading the thumbnails from disk adds to the latency, which defeats the purpose.

On backend image processing

It looks like the prevailing advice on Programmers.StackExchange is to keep a queue of image processing operations to be performed; the queue to be executed by an out-of-process ImageMagick worker process; results are added back to another "finished queue" to be handled by the backend.