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

Question

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

为了在结构上确保group_article仅与来自同一组的学生相关联，外键“publisher”和“app_group”取自加入实体group_member（1），而不是从student和app_group单独发出。这样，有权将新记录插入数据库的人不能引入不连贯的数据，例如添加一个学生写的文章甚至不是那个设计不佳的学生。现在，我想将这种方法概括为多个学生或多个小组。我现在有group_message，group_message_in和group_message_out这是一个继承链（group_message是Symfony中的抽象实体的基础，group_message_in和group_message_out都扩展它）：

最初，我计划将组外键嵌入基类（group_message）并让发件人/收件人（分别在group_message_out和group_message_in上）直接从学生中获取：

然而，根据第一个例子，这将使数据库易受不连贯性的影响，例如：来自A组的学生可以与针对来自B组的学生的消息相关联，这是不可取的（仅来自同一组的学生可以交换group_message）。

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

Answer 1

你的问题的关系解决方案看起来像这样：

您寻求的完整性将通过PK-FK关系以及使用groupName colums将学生分配到组来实现。

那么你的问题就变成了“我怎么能用Doctrine来做同样的事情？”

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

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

OO /关系鸿沟被称为“impedance mismatch”。不幸的是，这个术语比它揭示的更难掩盖。

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

我建议你也回顾一下Ted Neward的文章“The Vietnam of Computer Science”。

Answer 2

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

对象 - 角色模型。

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

现在作为领域专家，您可以阅读这种语言表达，并告诉我您的域名中是正确还是错误。请注意，我作为建模者所做的就是更改约束（由红色箭头显示），并且名为NORMA的ORM工具生成了您在此处看到的新语言表达。

当域专家同意模型符合要求时，生成SQL DDL需要几秒钟，然后可以使用它来在RDBMS中创建新的数据库模式。