当两张表非常相似时，什么时候应该合并？答案

【问题标题】：When two tables are very similar, when should they be combined?当两张表非常相似时，什么时候应该合并？
【发布时间】：2010-12-01 11:26:19
【问题描述】：

我有活动和照片，然后两者都有。现在，我有两个 cmets 表，一个用于与事件相关的 cmets，另一个用于照片 cmets。 Schema 与此类似：

CREATE TABLE EventComments
(
  CommentId int,
  EventId int,
  Comment NVarChar(250),
  DateSubmitted datetime
)

CREATE TABLE PhotoComments
(
  CommentId int,
  PhotoId int,
  Comment NVarChar(250),
  DateSubmitted datetime
)

我的问题是我是否应该将它们结合起来，并添加一个单独的交叉引用表，但我想不出一种正确的方法。我觉得应该没问题，你有什么想法？

编辑

根据 Walter 的回答（以及一些简单的阅读），我想出了这个：

CREATE TABLE Comments
(
  CommentId int,
  Comment NVarChar(250),
  DateSubmitted datetime
  CONTRAINT [PK_Comments] PRIMARY KEY
  (
    CommentId
  )
)

CREATE TABLE EventComments
(
  CommentId int,
  EventId int
)

CREAT TABLE PhotoComments
(
  CommentId int,
  PhotoId int
)

ALTER TABLE EventComments ADD CONSTRAINT FK_EventComments FOREIGN KEY (CommentId) REFERENCES Comments(CommentId)

ALTER TABLE PhotoComments ADD CONSTRAINT FK_PhotoComments FOREIGN KEY (CommentId) REFERENCES Comments(CommentId)

这些结构之间真的存在性能差异吗？对我来说，这似乎有点偏好。我确实看到了第二种模式的好处，如果我想为事件 cmets 或照片 cmets 添加一些特殊性，我有一个单独的表来执行此操作，如果我希望两者共享一个新属性，则有一个表可以添加新属性。

【问题讨论】：

标签： sql-server database-design data-modeling normalization

【解决方案1】：

Comments、PhotoComments 和 EventComments 以一种称为“泛化专业化”的模式相关联。这种模式是通过面向对象语言中的简单继承来处理的。设置将捕获相同模式的表架构有点复杂。

但这很好理解。在 Google 上快速搜索“泛化专业化关系建模”将为您提供几篇关于该主题的好文章。

【讨论】：

页面上最好的纯设计评论，恕我直言。
我做了一些研究并更新了问题。感谢您的输入
我非常不同意这个答案；在实践中，您正在乞求不一致、混乱的数据。 cmets如何删除？我经常看到它的设置就像 ScottM 在修改后的问题中实现的那样，并且几乎总是评论保留在评论中，但是 EventComments 或 PhotoComments 中的相关记录被删除，并且您在评论中留下了一个悬空的记录。

【解决方案2】：

如果将它们结合起来，就会弄乱密钥结构。您将必须具有可以为空的外键或键和类型的“软”键结构。我会把它们分开。

【讨论】：

是的，这就是我遇到的问题
它们与两个不同的“实体”有关，我认为它们不属于一起
虽然关联不同的实体，但都是cmets。
那是真的，如果它在我那里，虽然我会把它们分开。我不喜欢它们变得非常混乱的软键结构。
我想这取决于“他们都是 cmets”是否更重要，或者在概念上它是否总是只是“事件 cmets”或“照片评论”

【解决方案3】：

您可以将它们组合起来并添加一个字段来指示它是用于照片还是活动。

您将需要两个外键；一个用于照片，一个用于事件，但将它们放在一个表中允许您编写一组代码来处理所有 cmets。

但我很伤心。如果您将它们分开会更简洁，前提是您不必将两种评论类型混合在同一个列表中（这需要一个 UNION）。

【讨论】：

我如何识别评论与哪张照片或事件相关联，并且仍然确保参考完整性？
我同意它的一部分变得更复杂一些。

【解决方案4】：

我自己的个人设计风格是将它们组合起来，然后添加一个整数标志来说明评论的用途。如果我以后想添加更多内容，这也会给我提供可扩展性。

【讨论】：