正确的设计可以在结构上确保数据一致性

Question

在我目前的设计中，我有 app_group ，学生和 group_article ：

为从结构上确保 group_article 仅与同一组的学生相关联，外键“ publisher”和“ app_group”取自联接实体 group_member （1），而不是分别由学生和 app_group 发布。这样，有权将新记录插入数据库的人就不会引入不连贯的数据，例如添加由甚至不在该组中的学生编写的文章，而这将是糟糕的设计。现在，我想将这种方法推广到多个学生或多个小组中。我现在有 group_message ， group_message_in 和 group_message_out ，这是一个继承链（ group_message 是一个抽象链，实体，并且 group_message_in 和group_message_out都对其进行扩展）：

最初，我打算将组外键嵌入到基类（ group_message ）上，并具有发件人/收件人（分别位于 group_message_out 和 group_message_in ）直接从学生那里取得：

但是，按照第一个示例，这将使数据库容易受到不一致的影响，例如：A组的学生可以与不希望的针对B组学生的消息相关联（只有同一组的学生可以交换 group_message ）。

我很清楚我可以用代码来修改这种风险，但是我想要一个类似于（1）的解决方案，并且想知道这是否可以用Doctrine实现，因为MySQL本身可能有解决类似问题的方法受教义支持。

Answer 1

针对您的问题的关系解决方案如下所示：

通过PK-FK关系以及使用groupName列将学生分配到一个小组中，可以实现您寻求的完整性。

您的问题将变成“如何使用教义来做同样的事情？”

据我所知，Doctrine使用一组PHP库来创建其支持者所谓的“持久层”，该持久层存储了所谓的“实体”。在Doctrine中，术语“实体”是OO范例中“类”的同义词。 换句话说，Doctrine将类存储在数据层中。

现在我们可以看到问题了。 关系模式是一种关系结构，与类的集合完全是另一种人工制品。

OO /关系鸿沟被称为“ impedance mismatch”。不幸的是，这个术语模糊不清。

引自维基百科的文章：“已经进行了一些尝试来构建面向对象的数据库管理系统（OODBMS）来避免阻抗不匹配问题。但是，它们在实践中不如关系数据库那么成功，部分原因是OO原则的局限性作为数据模型的基础。”

我建议您还阅读Ted Neward的文章“ The Vietnam of Computer Science”。

Answer 2

这个新答案显示了对象角色模型，它生成的关系模式以及新约束所隐含的逻辑（红色箭头所示）

对象角色模型。

这是事实类型Student（.id）是Group（.name）的成员所断言的逻辑

现在，作为域专家，您可以阅读此口头表达，并告诉我您域中是True还是False。 请注意，作为建模人员，我所做的只是更改约束（如红色箭头所示），而名为NORMA的ORM工具生成了您在此处看到的新语言。

当领域专家同意该模型符合要求时，则需要花费几秒钟的时间来生成SQL DDL，然后该SQL DDL可用于在RDBMS中创建新的数据库架构。