Question

I have a search engine where each product item can have a thumbnail image for the summary and a larger image for the detail view.

Currently the image ids are stored as img_id and thumb_id in the Products table, and the attributes are kept in the Image table, (width, height, type) which needs a join to construct the image tag. Images are kept on a sub domain.

Products table has several million rows but not all products have images.

Should I do away with the image table and if so what method would you suggest to fetch the images?

Also there other smaller product catelogs being served on this system which have similar table structure

Thanks in advance.

I think what im looking for is here How to store images in your filesystem

Answer 1

You should think about the trade off between “optimal image saving” with different types (jpg, gif, …) and different imageURLs against the need safe all this information separately. An alternative would be the following:

• safe every image as jpg, for example
• use as image name $rowID_thumb.jpg and $rowID.jpg
• to avoid problems with your file system (over a certain value some file systems can’t handle a huge amount of data) you could create a directory clustering, for example 1/123/1234/123467.jpg, where 1234567 is the $rowID
• Think about fixed dimensions of your images to avoid the need to save width and height. There are enough image manipulation functions in php to get all the images to the same size

I would not store the name of the image in the db to save your independence 😉 In detail: you have a shop item with the ID 123. For this shop item exist an normal image an a thumbnail (only two images, otherwise my proposal is not the best solution!). I would not store anything about the images in the DB. Instead, use the ID 123 of the shop item to generate the filename programmatically, like getImagePathAndFilename($id) -> 1/123/123.jpg. In your upload process you have to take care that all the images have the same dimensions to avoid the need to save them separately.