一個主表，多個不同類型的附表該怎麼設計？

例如有以下的一個部落格：這個部落格儲存的資料比​​較雜
可以儲存
電影資料​​：
音樂資料：
商品資料：
圖片資料：
軟體資料：
要儲存這麼多的數據，表如何設計？
每種資料都有他獨特的特性，例如音樂有填詞人，作曲人，圖片有像素。
總不可能一個表，然後每個資料的不同特性都給一個欄位。
但是如果分錶的話，一個總表，記錄著類型和id等基本的，電影數據一個表，圖片數據一個表，等等.....這樣的話，如果是取出所有數據時，需要查詢多張表，導致效率比較低效。
有沒有什麼更好的設計解決方法？

回覆內容：

例如有如下的一個部落格：這個部落格儲存的資料比​​較雜
可以儲存
電影資料​​：
音樂資料：
商品資料：
圖片資料：
軟體資料：
要儲存這麼多的數據，表如何設計？
每種資料都有他獨特的特性，例如音樂有填詞人，作曲人，圖片有像素。
總不可能一個表，然後每個資料的不同特性都給一個欄位。
但是如果分錶的話，一個總表，記錄著類型和id等基本的，電影數據一個表，圖片數據一個表，等等.....這樣的話，如果是取出所有數據時，需要查詢多張表，導致效率比較低效。
有沒有什麼更好的設計解決方法？

可以用nosql,例如mongodb的document的方式儲存。
不必拘泥於字段。

若題主用的是mysql5.7， 可以把存儲數據的字段設置爲json類型的， 如

<code>//其他數據字段...


//电影数据，音乐数据等設計爲json
{
    “move”: {
    
    },
    "music" : {
    
    }
    
    //.......
}

</code>

分錶之後前台後的邏輯是要分開寫的：

前台讀取的時候不要直接讀取主表數據，透過具體類型的附表去關聯查詢主表。

後台直接讀取主表信息，但是不要讀取附表，只在後台列表中顯示主表內的數據，有需要展示附表的數據放到詳情頁面去。如果真的需要展示各個附表中的某些字段的話，那麼犧牲一些性能也是值得的，另外這種如果是所有附表都有的字段也要提到主表中

可以參考2樓的但如果還是希望單一種類資料庫的話可以參考wordpress的庫設計...他是將非主要或者可變類型屬性設計成key-value形式的副表存儲...思想是和nosql一致的....只是實作用了關係型資料庫來實作

或可以用EAV結構設計，表只存數據，在上面加上一層程式碼以滿足不同類型數據的需求。
具體方法搜一下EAV就可以了，magento是用這種方法實現的網店。