2

What is the correct way of storing the image files in the database. I am using file-paths to store the images.

But the problem is here. I have to basically show 3 different sizes of one image for my website. One would be used as thumbnail, the second would be around 290px*240px and third would be full size(approx 500px*500px). As it is not considered good to scale down the images using HTML img elements, so what should be the solution for it?

Currently, what I am doing is storing 3 different size images for one thing. Is there any better way?

Navneet Saini
  • 934
  • 4
  • 16
  • 33
  • Keep only original image path in the database. Other sizes should be created dinamically from the original. This **is** the solution – neoascetic Jun 15 '13 at 08:56
  • Using server-side scripting – neoascetic Jun 15 '13 at 08:57
  • Your only options are to calculate the images at runtime, or to store the different sizes somewhere. If you calculate them each time, you risk slowing things down for your users. If you store them, you will have a problem if you decide to change the image sizes in future. You must decide which of these possibilities fits your particular application better. – nurdglaw Jun 15 '13 at 08:59
  • "Better" is subjective. If you don't have space issues your current solution is fine. If you do, buy more space. Just never store images in MySQL. You can always compress your images too – Bojangles Jun 15 '13 at 09:00

3 Answers3

12

Frankly the correct way to store images in a database is not to store them in a database. Store them in the file system, and keep the DB restricted to the path.

At the end of the day, you're talking about storage space. That's the real issue. If you're storing multiple copies of the same file at different resolutions, it will take more space than storing just a single copy of the file.

On the other hand, if you only keep one copy of the file and scale it dynamically, you don't need the storage space, but it does take more processing power instead.

And as you already stated in the question, sending the full-size image every time is costly in terms of bandwidth.

So that's the trade-off; storage space on your server vs processor work vs bandwidth costs.

The simple fact is that the cheapest of those three things is storage space. Therefore, you should store the multiple copies of the files on your server.

This is also the solution that will give you the best performance as well, which in many ways is an even more important point than direct cost.

In terms of storing the file paths, my advice is to give the scaled versions predictable names with a standard prefix or suffix compared to the original file. This means you only need to have the single filename on the database; you can simply add the prefix for the relevant version of the image that has been requested.

Spudley
  • 166,037
  • 39
  • 233
  • 307
  • I am already following everything you stated in your answer. Just was a bit confused whether I am doing right or not. Perfect answer. Loved it. Thanks ;) – Navneet Saini Jun 15 '13 at 09:07
  • @Spudley What's the problem with storing multiple images in the database? Why dismiss it out-of-hand? The advantage I can see is one of maintenance. With images stored in the filesystem you need a backup strategy for the fs as well as the database. If you store them in the db then you only need a backup strategy for that. – nurdglaw Jun 15 '13 at 09:13
  • 1
    @nurdglaw: believe me, I've worked with plenty of systems where folk thought it was a good idea to put images in the DB. It has proved to be a massive mistake in every single case. It adds a lot of complexity to the system and invariably has a significant performance overhead (no matter how quick your DB and your server-side code, they'll never be as quick as a direct read to the file system; very often it's a lot slower). There are cases where it's justified, but they're few and far between, and generally only apply if you're doing dynamic modification to the image whenever you serve it. – Spudley Jun 15 '13 at 09:27
  • @Spudley OK, thanks for spelling it out. I'm surprised, but will accept the _Voice of experience_ - I have none :-) – nurdglaw Jun 15 '13 at 19:15
  • 1
    @nurdglaw - worth a read here: http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay – Spudley Jun 15 '13 at 21:03
  • @Spudley. Thanks, an interesting read! (Mind you, that's not what I said when I saw the number of replies to that question :-) ) – nurdglaw Jun 15 '13 at 21:34
5

Nothing wrong with storing multiple versions of the same image.

Ideally you want even more – the @2x ones for retina screens.

You can use a server side script to generate the smaller ones dynamically, but depending on traffic levels this may be a bad idea.

You are really trading storage space and speed for higher CPU and RAM usage to generate them on the fly – depending on your situation that might be a good trade off, or it might not.

Rich Bradshaw
  • 71,795
  • 44
  • 182
  • 241
1

Agree with rick , you can store multiple size pics as your business requirements. You should store Image in folder on the server and store its location in database. Make hierarchy in the folder and store low res images inside the folders so that you can always refer to them with only one address. you can do like this in your web.config

<add key="WebResources" value="~/Assets/WebResources/" />
<add key="ImageRoot" value="Images\Web" />

make .233240 and .540540 folders and store those pictures with same name inside them so you can easily access them.

Ali Umair
  • 1,386
  • 1
  • 21
  • 42