在数据库中写入评论表答案

【问题标题】：Writing Comments table in database在数据库中写入评论表
【发布时间】：2008-11-28 02:01:45
【问题描述】：

我正在开发一个社交网络系统，该系统将拥有来自多个不同位置的 cmets。一个可以是朋友，一个可以是事件，一个可以是群组——很像 Facebook。我想知道的是，从实际的角度来看，编写 cmets 表的最简单方法是什么？我应该在一个表中完成所有操作并允许外键访问各种不同的表，还是每个不同的表都有自己的注释表？感谢您的帮助！

【问题讨论】：

标签： database database-design

【解决方案1】：

我认为单 cmets 表是更优雅的设计。不过，不要考虑多个 FK，而是考虑一个中间表 - CommentedItem。因此，Friend、Event、Group 等都具有 CommentedItem 的 FK，并且您为每个表中的每个新行创建一个 CommentedItem 行。现在 Comments 只需要一个 FK 到 CommentedItem。例如，要获取给定朋友的所有评论：

SELECT * FROM Comment c
JOIN CommentedItem ci on c.CommentedItemId = ci.CommentedItemId
JOIN Friend f on f.CommentedItemId = ci.CommentedItemId
WHERE f.FriendId = @FriendId

【讨论】：

谢谢。这听起来是个好主意，但我很好奇如果你可以直接使用中间表，为什么你会使用它？是因为性能问题吗？
因为如果不使用中间表，则每个潜在的可评论项表都需要一个单独的“FK”列。这会导致非常尴尬的情况，如果数据库损坏，您可以将 1 条评论附加到不同类型的多个不同项目。
@Matt：仍然觉得没有中间表我们可以做得很好。我们在 cmets 表中有一个列，它应该足够并保留可评论项表中的 id。
啊，马特，我明白你在说什么。这很有意义。但是，如果您有一个具有多种可能性的 commenteditems 表，您还会遇到同样的情况吗？你怎么能隔离评论类型？
我知道这是一个老问题/答案，但我在这里看不到解决方案，您不能将 FK 加入朋友/事件/组...因为您事先不知道cmets 并且如果您将 FK 放在中间表中，那么您将问题移到那里，因为您不知道项目的种类，并且您需要尽可能多的 FK 可注释项目。我错过了什么吗？

【解决方案2】：

我都做过，答案取决于具体情况。对于你想要做的事情，我会做一个“评论”表，然后单独的“链接器”表。这将为您提供最佳性能，因为您可以实现“Perfect Index”。

我还建议在 Comments 表中放置一个“CommentTypeID”字段，以提供有关您将从哪个链接器表中提取附加详细信息的“线索”。

编辑：CommentTypeID 字段不应在索引中使用，而只能在代码中使用。

【讨论】：

好的，这很有道理。那么最好有一个列出“朋友”、“事件”、“组”等的“Comment_Types”表吗？然后将其作为 Comments 表的外键？

【解决方案3】：

需要注意的一点是，如果您不使用高度规范化的数据库，它有时会导致 IO 行链接和表扫描。

我相信 oracle 建议执行大约第三范式的规范化模型。

【讨论】：

【解决方案4】：

这是与this one 相同的问题。

编辑：根据评论，尚不清楚这是一个等效问题，因此我在下面将其拼写出来。

这两个问题都询问有关数据库性能问题的项目（两者都恰好是社交网络，但这只是巧合）。两者都有一组不同的对象，它们共享一个共同的属性集合（一个是事件，发生在每个对象上，另一个是发生在每个对象上的注释）。

这两个问题都有效地询问了创建一个结合不同的共同特征的 UNION 查询，或者使用适当的外键将它们分解到一个公用表中是否更有效。

我认为它们是等价的；对一个的最佳答案将同样适用于另一个。

（如果您不同意，我很高兴听到原因；请发表评论。）

【讨论】：

我不同意马克的观点，但我很感激，我需要澄清我的理由，而不是仅仅重申我的立场。已编辑。

【解决方案5】：

我会选择polymorphic associations。许多现代 Web 开发框架开箱即用地支持它，这使其成为处理此类关系的最简单、最轻松的方式。

【讨论】：

【解决方案6】：

其实你可以去http://www.zazazine.com看看他们的文章。你可以在那里找到答案

【讨论】：