How to Design multiple tables of different types in a master table?

For example, the following blog stores a lot of data that can store movie data: music data: product data: image data: software data: to store so much data, how to design tables? Each type of data has its own unique features, such as music with lyrics, publisher, pictures... for example, there is a blog: the data stored in this blog is relatively complex.
Storage Available
Movie data:
Music data:
Product data:
Image data:
Software data:
How to design a table to store so much data?
Each type of data has its own unique features, such as music being filled with likes, publisher, and pictures being pixels.
It is impossible to create a table, and each data has a field for different features.
However, for table sharding, a summary table records basic types and IDs, movie data, image data, and so on ..... in this case, when retrieving all the data, you need to query multiple tables, resulting in inefficiency.
Is there any better design solution?

Reply content:

For example, the following blog stores a lot of data:
Storage Available
Movie data:
Music data:
Product data:
Image data:
Software data:
How to design a table to store so much data?
Each type of data has its own unique features, such as music being filled with likes, publisher, and pictures being pixels.
It is impossible to create a table, and each data has a field for different features.
However, for table sharding, a summary table records basic types and IDs, movie data, image data, and so on ..... in this case, when retrieving all the data, you need to query multiple tables, resulting in inefficiency.
Is there any better design solution?

You can use nosql, such as mongodb's document storage.
Do not stick to fields.

If the subject usesmysql5.7, You can set the field of the stored recordsjsonType, such

// Other numeric fields... // movie data, music data, and other settings are as json {"move" :{}, "music ":{}//.......}

After table sharding, the foreground logic should be written separately:

Do not directly read data from the master table when reading data from the front-end, and query the master table through a specific type of table.

The background directly reads the information of the primary table, but does not read the attached table. only the data in the primary table is displayed in the background List. The data in the attached table must be displayed on the details page. If you really need to display some fields in each table, it is worthwhile to sacrifice some performance. In addition, if all the fields in the table also need to be mentioned in the main table

You can refer to the second floor, but if you still want a single type of database, you can refer to the wordpress library design... it designs non-primary or variable type attributes into a sub-table store in the form of key-value... the idea is consistent with nosql .... only relational databases are used for implementation.

Alternatively, you can use the EAV structure design to store only data in tables and add a layer of code to meet the needs of different types of data.
You can search for EAV in specific ways. magento is an online store implemented in this way.