Sql server 使用主id的数据结构

我有一个数据库，表a和表B是一对多的关系。因此，A中的一个实体可以分配给B中的多个不同实体。A和B各自有自己的特定字段，但也有与A或B相关的字段和工作流，这些字段和工作流基本上是相同的数据，但仅与A或B相关

例如，A中的一个实体由于不同的原因可能有多个注释，B中的实体也可能有多个注释。由于一条记录可能有多个注释，我必须在表A和B之外有一个相关的注释表。我不想有两个注释表，一个用于A，另一个用于B，因此，我建立了一个MasterID表，它与a和B都相关，并强制执行引用完整性。这意味着，当我想在a或B中添加记录时，我必须确保MasterID表中已经存在MasterID。还有其他表具有相同类型的功能，注释只是一个例子，但是如果我没有使用MasterID，我必须为a和B分别创建多个表

所以我的问题是，这是正确的方法吗？还有别的办法吗？前端将处于Access中，因此我在确保在a或B中创建新记录之前创建MasterID时遇到了一些问题

MasterID(MasterID)

TableA(TableAID, FK_MasterID)

TableB(TableBID, FK_MasterID, FK_TableAID)

Comments(CommentID, MasterID, Comment)

---

谢谢你的帮助。

根据我对这个问题的理解，我认为这太复杂了，没有什么价值。如果我理解正确，你有一个像图片一样的情况，你想让评论的关键是独特的

创建第四个表可能可行，但会增加不必要的复杂性

您可以改为将Comments表的键设置为两列的复合键，一列是序列号，另一列是指示父表的字符字段。所以你会得到像（A，1），（A，2），（B，3），（A，4），（B，5）这样的键

这样，您就不需要主表，也不需要表A或B中的FKs

---

从纯数据设计的角度来看，您的思路是正确的，但并不完全正确。您可以使用实体子类型划分方法，其中

A

和

B

是另一个实体的子类型（

MasterID

）。正是这种超类型实体吸引了评论。然而，对于真正的子类型来说，

A

的PK和

B

的PK将是

MasterID

的FK

---

按照您设计表的方式，它们有两个候选键。如果您消除了多余的候选键，那么您就有了一个标准的实体子类型模式，这是一种合法且常用的设计方法。

谢谢您提供的信息。注释不是A和B之间具有相似数据的唯一表，而是A和B之间需要的一组多值依赖关系数据的示例，这些数据类型相同，但对A或B也是唯一的。我稍微改变了结构，所以现在有了：TableA（PK_MasterID）；表B（PK_MasterID）；MasterID（PK_MasterID）；注释（PK_CommentID、注释、FK_MasterID）。向a或B添加记录仍然不像正常情况下那么容易，因为MasterID必须首先存在，但这似乎是正确的，或者您有进一步的建议吗？再次感谢。@user3043701-您更新的结构是正确的。这并不容易实现，特别是在Access中，因为您没有存储过程或其他方法的全部功能，这些存储过程或方法允许您将多个表写入打包到单个事务（逻辑工作单元）中。然而，这种结构在理论上是最正确的，如果有必要的话，它将在将来很好地移植到更全面的DBMS中。是的，我注意到了这带来的困难。它几乎不能用了。在A和B之间没有足够相似的数据成为MasterID表的一部分（比如FirstName/LastName），所以我只有一个自动编号的MasterID字段。Access不允许我向只有自动编号主键的表中添加任何记录。我希望MasterID会自动编号，然后子表会继承它作为主键，但运气不好。因此，虽然正确，但解决方案似乎不起作用。不确定还有什么可以尝试。@user3043701如果最重要的事情是让访问愉快，那么最好的折衷办法是有两个不同的

注释

表，每种表一个（

A

和

B

）。通过这种方式，您可以将FK定义为Access中的关系，然后Access将为您提供各种无代码的好处。然后，如果您想拥有一个包含所有注释的单一视图，您可以定义一个视图（联合查询），该视图将它们聚集在一个看起来有点像您的第一个想法的视图中。