Store image URL in database or let class determine it

Hi guys,

Simple question here which I’ve encountered more than once.

When you’re storing an image say for a product in a database, as far as I know the recommended practice is not store the image in a binary or similar field but just store a URL to the image somewhere on the server.

e.g. images/products/thumbnails/image.jpg

However, why would we do this instead of let the thumbnail fetching logic be stored in the class in question.

Say our application creates Product objects of the form:

class Product {
   var $id;
   //.. stuff
   function thumbnail() {
       return 'images/products/thumbnails/' . $this->id . '.jpg';

If we can store the thumbnail (and full size) image paths in the Product class or some Configuration-type class, and the thumbnails/images will have a consistent naming structure, i.e. whatever file we uploaded is renamed in a consistent format, is there a need to store any sort of image information at all in the database and just handle it at the object level?

One thing you could say is that this way does lock us into only returning images of a certain extension (.jpg) but:
a) we are resizing the images so we might as well resample them all into jpgs (or pngs) while we’re at it
b) we could store the extension/image type in the database

I’ve done both ways in the past and both have worked fine for the level of application I’ve worked with.

Does anyone have any thoughts/advice/comments about which route to take? :slight_smile: thanks in advance!

Ah, sorry I mis-interpreted the original question.

Oh well it’s another option worth considering :slight_smile:

Brandon - thanks for your reply too! I can see how the naming convention change could cause an issue.

So you were storing product image paths in a seperate database table so a product could have multiple images?

by the way, I would expect another benefit of filesystem images would be SEO? do database-generated images show up in Google searches?

Tom, just to clarify, the OP doesn’t want to store the image as a database blob, but simply the uri path as a string.

IMO, there is no reason not to store the image path in the database. There will come a time when an exception needs to be made or your naming structure needs to become more advanced and the database will be able to adapt easier in most cases.

For a number of years we used to rely on a specific naming convention for our product images. We took it a step further than you are currently and we actually had multiple product images. The issue would become that some products had 4 images whlie others at 1. That meant that we would were doing a lot of the same file_exists checks over and over which caused some overhead. Also, we eventually had 1000’s of files in the same directory. Our host recommended that we started organizing into folders, but that didn’t work with our naming conventions. Now we have moved to storing the file paths in the database and I think the performance and flexibility have both improved. YMMV

Hi Tom,

Thanks for a great reply! I tend towards the filesystem for storing images mostly for the performance benefits and direct access/manipulations of the images.

again, thanks a lot for your comments.

For performance, yes storing them in the filesystem is better, however, there are several advantages to both methods:

In favour of database storage:

-Easy backup- you can back up the database and all the related images with a database dump
-Better portability- you can move your entire site to a different system and not worry about directory structure contstraints or naming conventions
-Scalability- if you fill up the drive containing the images, you have to get a new/bigger hard drive a database can be configured to span multiple disks/partitions even servers.
-One step permissions, only people with access to the database have access to the images. You don’t need to re-create the permissions in the file system

In favour of file system storage:

-Performance a) Retrieving binary data from a database is slower than the filesystem (I benchmarked this myself using images for a paper I wrote at university)
-Performance b) if you want to display the image and a related database record (e.g. caption for the image) you need 2 connections to the database (over two http requests, one for the caption, one for the binary data. For the filesystem you still need two HTTP requests but only one will access the database.)
-Performance c) in most large scale web applications, the database is the bottleneck. Do you really want more queries than you need?
-You can view/access the image without going through the database.
-If you need to do filesystem type operations such as zipping a group of images it becomes more difficult when they’re in the database.

As with most things, there’s no correct answer and it depends how you rate the items I mentioned above.