db設計：評論多個實體

Question

所以我目前有兩個實體可以評論，比如Pic和Text。

我一直在尋找這個問題的一個可能的DB設計： Implementing Comments and Likes in database 在那裏，我們就會有一個Comment表：

#comment_id 
#entity_id 

現在，我的客戶，這是技術嫺熟的爲好，沒有按不喜歡爲可評論的實體建立一個共同的超級類的想法 - 無論出於何種原因，我都不知道。

所以我目前有一個Comment表，它與Text和Pic（我在DB上做得相當不錯，但我不是專家）有任何關係。這意味着我有一個Comment表：

#comment_id 
#pic_id 
#text_id 

這將導致，對圖片的意見，有，來查詢pic_id不爲空（以同樣的方式對文本的意見，查詢text_id != null） 。這對我來說感覺很奇怪（不過，我們可能有更多的查詢是「get_comments_for_pic」或「get_comments_for_text」，這將需要通過pic_id或text_id查詢）。

但客戶推動每個Text_Comment和Pic_Comment都有單獨的表格，它們基本上可以達到相同的效果，但會更好地區分不同的評論。

是否有其他理由相比現在看不到的其他理由？任何其他建議如何實施？

Answer 1

您的客戶是對的。你的方式，你的數據庫表將有許多空條目，這通常是一個壞的數據庫設計的標誌。每一行的大小會更大。另外，您需要在NULL值過多的字段中使用兩個索引，並且DB表格的大小將增加一倍，而不是分割爲兩個數據庫表格，也會增加相應索引的大小。

總體而言，根據您的客戶建議，更小的行，更小的數據庫表，更小的索引=>更快的性能。