所以我目前有两个可以发表评论的实体，比如Pic和Text。
我正在考虑这个问题以寻找可能的数据库设计：
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的方式相同）。这对我来说感觉很奇怪（尽管如此，我们可能有更多的查询是＆＃34; get_comments_for_pic＆＃34;或＆＃34; get_comments_for_text＆＃34;需要通过 pic_id或text_id来查询。
但客户端正在推动为每个Text_Comment和Pic_Comment分别设置表，这些表基本上会达到相同的效果，但会更好地分隔不同的评论。
是否还有其他理由偏爱另一个我现在无法看到的？关于如何实现这个的任何其他建议？
答案 0 :(得分：0)
您的客户是对的。你的方式，你的数据库表将有许多NULL条目，这通常是糟糕的数据库设计的标志。每行的大小会更大。此外，您将需要具有太多NULL值的字段中的两个索引，并且DB表将是大小的两倍，而不是分成两个DB表，还会增加相应索引的大小。
总的来说，根据您的客户端建议，较小的行，较小的数据库表，较小的索引=＆gt;更快的表现。