A main table, how many different types of schedules should be designed?

For example, there is a blog: the blog store data comparison Miscellaneous
can store
Movie Data:
Music data:
Product data:
Image data:
Software data:
How is the table designed to store so much data?
Each kind of data has his unique characteristics, such as music has lyrics, composers, pictures have pixels.
It's not always possible to have a table, and then give each data a different attribute to a field.
But if a table, a summary table, record the type and ID and other basic, movie data a table, picture data a table, and so on ..... In this case, if you are fetching all the data, you need to query more than one table, resulting in inefficient efficiency.
Is there any better way to design the solution?

Reply content:

For example, there is a blog: the blog store data comparison Miscellaneous
can store
Movie Data:
Music data:
Product data:
Image data:
Software data:
How is the table designed to store so much data?
Each kind of data has his unique characteristics, such as music has lyrics, composers, pictures have pixels.
It's not always possible to have a table, and then give each data a different attribute to a field.
But if a table, a summary table, record the type and ID and other basic, movie data a table, picture data a table, and so on ..... In this case, if you are fetching all the data, you need to query more than one table, resulting in inefficient efficiency.
Is there any better way to design the solution?

It can be stored in a way that is nosql, such as MongoDB's document.
Don't be stuck in a field.

If the main problem is mysql5.7 , you can set the stored storage field json as a type, such as

//其他數據字段...//电影数据，音乐数据等設計爲json{    “move”: {        },    "music" : {        }        //.......}

The logic behind the table after the desk is to be written separately:

When reading from the foreground, do not read the main table data directly, and query the main table by the specific type of schedule.

Background directly read the main table information, but do not read the schedule, only in the background list to display the data in the main table, there is a need to show the schedule of data on the details page. If you really need to show some of the fields in each schedule, then sacrificing some of the performance is also worthwhile, and if all the schedules have a field to refer to the main table

can refer to the 2 floor, but if you still want a single kind of database, you can refer to WordPress library design ... He is a secondary table store that designs non-primary or variable-type properties into Key-value form ... Thought is consistent with nosql .... Just implemented using relational database to implement

Or you can use the EAV structure design, the table only saves data, and adds a layer of code on it to meet the needs of different types of data.
Specific methods to search EAV on it, Magento is to use this method to achieve the online shop.

