How to organize a database for photo thumbnails?

Question

MySQL

Hello.
I develop, for home needs, photo hosting. There will be up to 7 thumbnails for each photo. I need to save the dimensions and size of the thumbnails. Taking into account the path, as a result, 28 attributes are obtained. And that's just the thumbnails. In addition, there are additional 15 attributes that characterize the photo. As a result, 43 attributes. We have my small horizons, this is a lot.
An alternative option came to mind, namely, to take out the miniatures in a different ratio.
photos
id | otherAttr
thumbs
id | photo_id | path | width | height | size
This variant is convenient in size selection, but it enlarges the database many times over. When adding 1000 photos (and there will be more), there will be 7000 rows in the thumbs relation.
What do you think? Which of these options is the best? Surely there is an alternative?
Thank you
______________________________________________________________________________ I
decided on the database structure for the photo gallery application.
The result was a concise scheme, with the ability to combine two types of files - photo and video.
Advantages:
1) No frills, different types of media files can be combined into albums;
2) For comments and bookmarks, one relation (table) is enough;
3) Thumbnails of media files are taken out in the photos relation, which allowed the scheme to be brought to 2NF;
4) The items relation has been simplified by 5 attributes.
As a result, such a scheme turned out to be easier to moderate. The application provides a function to select thumbnails by dimensions corresponding to the display structure. For example, when displaying a gallery in the justfield style, the system looks at the height of the image, and selects files with a similar height size. This allows you not to download heavy files.
Disadvantages:
1) When adding one entry to items, up to 5 entries will be added to photos.
Now it is difficult to judge this shortcoming. Soon, I will check this point by writing to items from 1 million lines.

Answer 1

If these thumbnails are of a standard size, then it is enough just to make the corresponding folders like thumbs_90x60 and do not write anything to the database.
When trying to read a file that is not in such a folder, redirect the request to a script that generates the desired thumbnail in the folder and returns the result.
Well, either immediately when uploading a photo, generate all the thumbnails.

Answer 2

Producing columns that in theory will be half empty is a bad idea. Especially from the point of view of the expansion "for later" this is also not very good.
On the other hand, 7000 lines is "about nothing" - not a load for SQL.

Answer 3

1) 1k + 7k ... yes, at least 100k + 700k - garbage. You will run into the fact that you do not have enough space for the image files themselves much earlier than the fact that the database cannot cope with the number of records.
2) 43 attributes is if you write everything in one table. Even this is not much, although it is surprising, but if you put the thumbnails in the next table, you get 15 attributes in one and 4 in the other - nothing at all.

Answer 4

the main parameters by which the search will go, etc. make separate columns, other not very important attributes can be in one field in json format.
And as I understand it, you will have the photo itself with attributes and separate thumbnails for this photo? These entities must be in different tables and do not forget about foreign keys to ensure integrity ...
something like:
main_photo
id | path | width | height | size | other_attr
min_photo
id | main_photo_id | path | width | height | size | other_attr

Answer 5

If for home needs - what prevents, for example, to store it in a directory and give it to the right size with a php script?