11

I am implementing a project that deals with a significant amount of images.

In your opinion what are the cons/pros of the following two approaches:

  • I need to store thousands of items, each item as several string properties and an image.
  • Each item as an ID (integer)
  • MyISAM tables
  • How would you store the images:
    • approach 1: store images into a directory and each image named as ID.jpg
    • approach 2: store images into the database as a binary BLOB

Using approach 1 I can access the image directly and that's it

<img src="same_directory/10.jpg" />

Using approach 2, I can still use the above HTML, but need to redirect that jpg access to a PHP script which will return the real image from the DB.

In terms of performance which one do you think its faster?

I am keen to approach 1.

cmancre
  • 1,061
  • 3
  • 11
  • 23
  • 2
    Generally speaking, storing large BLOBs in the database really hampers performance. If all the images are very small files, it is not so bad. – Orbling Dec 06 '10 at 14:45
  • If all images are not jpg do compress before save in database. – A G Dec 06 '10 at 14:45
  • possible duplicate of [Store pictures as files or in the database for a web app?](http://stackoverflow.com/questions/561447/store-pictures-as-files-or-in-the-database-for-a-web-app) – shamittomar Dec 06 '10 at 14:48

5 Answers5

5

advantages of approach 1:

  • Retrieving the flat file form webserver is more faster.
  • most of the web hosts likely to follow this approach.
  • the file system is faster for flat file storage.

advantages of approach 2:

  • All your data is kept in one place, if you migrate your website/database the images will just be there
  • Its easier to sort/delete/etc...
  • Since you have to serve it via a PHP script, you can perform additional things such as security if required, or image processing (obviously you can do this with flat file too, but you have to make sure the security cant be bypassed by leaving the images in a public directory).

considering performance approach 1 is best to proceed.

kongaraju
  • 9,344
  • 11
  • 55
  • 78
2

Storing on filesystem is faster.

shamittomar
  • 46,210
  • 12
  • 74
  • 78
1

I'm be tempted to use the first approach as there's no real value in cluttering up the database with image data. (Fetching the data from the database will also be significantly slower than simply loading it off disk.)

However, as an suggestion you might not want to store the full path on disk to the image in the database table, to aid portability in the future. (i.e.: Just store the portion of the path and filename off a 'known' base folder.)

John Parker
  • 54,048
  • 11
  • 129
  • 129
0

Keep the image files as image files on the server to lower your DB load and allow the server to handle caching etc. Overall it really depends on the kind of images we're talking about. Small thumbnails (e.g. for file icons) wouldn't be that bad, but I wouldn't store whole images in the DB. In general I guess the file system approach would be faster.

Mario
  • 35,726
  • 5
  • 62
  • 78
0

Lets investigate problem on web browser. When you load page with 10 pictures saved in database. You browser send new http request to the server. Each request init DB connection and server side script. Or just read static image from the file system.

what will be faster?

Other part - get data from file system or database. If we do not use cache for the database (but for 10 GB of images you should have 10 GB RAM to cache this data). Database and HTTP server reads data from file system in any case. But I think HTTP browser reads data faster then Database server.

Only one thing cons for the Database storage - very easy to migrate data from one server to other. But this is not matter for system performance.

And do not forget make path for images like /a/b/c/abc.jpg - it will be faster for big amount of images, then put all images in one directory.

Andrey Korolyov
  • 996
  • 6
  • 10