Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

MySQL Database design - Storing Images - Single table or multiple tables

I am currently working in a product where different types of images like product images, user profile pictures, logo etc. are there. I need a database with good query performance.

I got two DB designs in mind.

OPTION 1. - Storing all images in a single table with id,title, url_full, url_thumb , status and timestamp field

Advantages

  1. I can use single ImageModel file to insert delete / update data. So there will be no multiple logic for image storage. It is just a single logic, "storing in a single table". So whenever image has to be saved, I can call the method of ImageModel

Disadvantages

  1. If there are lot of product images and less user images, the user image querying will become slow due to the huge number of products.

OPTION 2. - Storing different type of images in different tables with id,title, url_full, url_thumb , status and timestamp field

Advantages

  1. Increased number of records in one section won't affect the query speed of other

Disadvantages

  1. Has to write separate model files / functions for each image type.
  2. Whenever image has to be stored, type needs to be specified.

My question is , which is the better approach. Is the advantages and disadvantages a real concern.Also if there are any other advantages / disadvantages, please list. Or if there are any other god db designs, please suggest.

Please answer based on the practical scenario where there are lots of products and users.

like image 940
Jinu Joseph Daniel Avatar asked Sep 24 '16 08:09

Jinu Joseph Daniel


People also ask

How does MySQL store images?

A Binary Large Object ( BLOB ) is a MySQL data type that can store binary data such as images, multimedia, and PDF files.

What data type is suitable to store images in MySQL?

In MySQL, the preferred data type for image storage is BLOB.

Which database is best for storing images?

Store in Couchbase a metadata JSON document for each object, maybe a small thumbnail image at most. In that document is data you need about that object in your application quickly, but also a pointer to a purpose built object store like S3, a file system or HDFS. You will get the best of all worlds.

Is it good practice to store images in database?

Storing images in a database table is not recommended. There are too many disadvantages to this approach. Storing the image data in the table requires the database server to process and traffic huge amounts of data that could be better spent on processing it is best suited to.


1 Answers

This began as a long comment so I decided to post it as an answer. Storing different types of images in different tables sounds like a bad idea to me. For one thing, how will that design scale if, for example, new types of categories appear later? Would you then be able to cope with adding an arbitrary number of new image tables? Also, querying all images would require either a series of joins or unions, which could be costly.

You mentioned the following advantage to a multi image table schema:

Increased number of records in one section won't affect the query speed of other

If you use a single image table with an index on the type column, then increasing the number of records of one type won't necessarily increase querying for images of a second type. And here is a disadvantage to a single image table which you gave:

If there are lot of product images and less user images, the user image querying will become slow due to the huge number of products.

It is true that adding more records will generally slow down querying. However, having an appropriate index on the type should greatly diminish this problem.

A single image table with appropriate indices seems much better.

like image 191
Tim Biegeleisen Avatar answered Oct 01 '22 09:10

Tim Biegeleisen