用“选定的”成员来建模组成员资格。数据库中的成员

Question

在我的数据模型中，我有一个实体 Group 和另一个实体 GroupMember。一个Group由一个或多个GroupMember组成，但一个GroupMember只能同时属于一个Group 。到目前为止没有问题，在数据库中 GroupMember 有一个 Group id 的外键。但是现在我想让其中一名成员成为“默认”或“选定”成员。应该始终只有一名选定的成员，不多也不少。

我尝试在实体框架中对此进行建模，其中具有一个 1-* 关联来建模组成员身份，以及一个 (0..1)-1 关系来保存 Group 内所选 GroupMember 的实例。

但是现在我显然遇到了问题，当插入 Group 和 GroupMember 的实例时，我收到一个错误，实体框架无法确定插入项目的顺序，因为 Group 需要有效的 GroupMember 作为默认成员，但除非不引用现有的 Group 实体，否则无法插入 GroupMember。可以说是先有鸡还是先有蛋的问题...

最简单的方法可能是可选地建立其中一个关系，但这将消除我希望在正常数据库操作期间拥有的约束。理想情况下，实体框架应以任意顺序将数据插入数据库，并且数据库应仅在事务结束时检查约束违规情况。

另一种方法是将所选成员建模为 GroupMember 中的布尔属性“IsSelected”。但是我不确定如何确保仅使用实体框架设计器同时只有一个选定的成员（我想尽量避免直接使用数据库）。

您能否提供任何指导来处理此问题的首选方法是什么？谢谢！

Answer 1

对此进行建模的正确方法是使用关联表：

+-------+              +--------+                 +--------+
| Group |--------------| Member |-----------------| Person |
+-------+ 1          * +--------+ 1             1 +--------+
    | 1                                               | 1
    |                                                 |
    |                                                 |
    | 0..1                                            |
+--------+                                            |
| Leader |--------------------------------------------+
+--------+ 0..1

I'我假装“领导者”是对群体中“特殊”人的准确描述。您应该尝试使用比“selected”更具描述性的名称。

该架构如下所示：

CREATE TABLE Group
(
    Id int NOT NULL PRIMARY KEY,
    ...
)

CREATE TABLE Person
(
    Id int NOT NULL PRIMARY KEY,
    ...
)

CREATE TABLE Member
(
    PersonId int NOT NULL PRIMARY KEY
        CONSTRAINT FK_Member_Person FOREIGN KEY REFERENCES Person (Id)
            ON UPDATE CASCADE ON DELETE CASCADE,
    GroupId int NOT NULL
        CONSTRAINT FK_Member_Group FOREIGN KEY REFERENCES Group (Id)
            ON UPDATE CASCADE ON DELETE CASCADE
)
CREATE INDEX IX_Member_Group ON Member (GroupId)

CREATE TABLE Leader
(
    PersonId int NOT NULL PRIMARY KEY
        CONSTRAINT FK_Leader_Person FOREIGN KEY REFERENCES Person (Id)
            ON UPDATE CASCADE ON DELETE CASCADE,
    GroupId int NOT NULL
        CONSTRAINT FK_Leader_Group FOREIGN KEY REFERENCES Group (Id)
            ON UPDATE CASCADE ON DELETE CASCADE,
    CONSTRAINT U_Member_Group UNIQUE (GroupId)
)

它表达以下有关关系的信息：

• 存在一个组，期间。它可能有也可能没有成员。如果它没有成员，那么根据定义它也没有领导者。它仍然存在，因为稍后可能会添加新成员。

• 一个人存在，就这样。一个人不会仅仅因为他/她的群体不存在而不再存在。

• 一个人可以是一个且仅有一个群体的成员。

• 一个人也可能是一个团体的领导者。一个团体一次只能有一名领导者。群组的领导者可能也可能不被视为成员。

您可能认为这种关系设计所施加的约束比您问题中提出的约束要宽松得多。你是对的。这是因为您的问题是将数据模型与业务/域需求混为一谈。

除了此模型之外，您还应该有一些业务规则，由您的应用程序强制执行，例如：

• 如果群组没有成员，则将其删除/停用/隐藏。

• 如果停用/隐藏的组获取成员，则会重新激活/显示。

• 一个人必须是某个团体的成员。添加新人员时必须提供此信息（不必是现有组，可以是新组）。如果一个人的成员资格组被删除，这应该会触发一个异常过程；或者，如果群组仍有成员，则不允许删除该群组。

• 一个团体有成员就必须有领导者。如果将新人添加到空组中，则该人将成为领导者。如果领导者（人）被删除，则应根据某些标准自动选择新的领导者，否则应触发例外流程。

为什么这是“正确”的设计？

首先是因为它准确地描绘了实体及其关系的独立性。团体和个人实际上并不相互依赖；这只是您的业务规则规定您对没有群组成员资格的人员或没有任何成员或领导者的群组不感兴趣。

更重要的是，因为索引和约束更加清晰：

• 查询组的成员速度很快。
• 查询一个人的成员资格很快。
• 查询一个组的组长速度很快。
• 查询同时也是领导者的速度很快。
• 删除群组将自动删除所有群组成员/领导者。
• 删除某人将自动删除所有群组成员资格/领导地位。
• 更改成员资格仍然是单个 UPDATE 语句。
• 改变领导层仍然是一个UPDATE语句。
• SQL Server 不会抱怨多个级联路径。
• 每个表最多有 2 个索引，位于您希望建立索引的列上。
• 您可以轻松扩展此设计，即适应不同类型的会员资格。
• 成员资格/领导层的变更永远不会干扰简单的查询（例如按姓名查找人员）。
• 每个 ORM 都可以毫无问题地处理这个问题。通常，您会将其视为多对多，但您也许可以将其实现为可为空的一对一。

所有其他解决方案都有一些严重的致命缺陷：

• 将GroupId放在Person和LeaderId上on Group 会导致循环，除非使至少一列可为空，否则无法解决该循环。您也无法CASCADE其中一种关系。

• 将 GroupId 放在 Person 上并将附加 IsLeader 放在 Person 上不允许您强制执行上限绑定（每组 1 名领导者），无需触发。实际上，从技术上讲，您可以使用过滤索引（仅限 SQL '08），但它仍然是错误的，因为 IsLeader 位实际上并不指定关系，并且如果您不小心更新了 GroupId 但忘记 IsLeader 那么你突然让这个人成为一个完全不同的群体的领导者，并且可能违反了至多一个约束。

• 有些人会选择将GroupId添加到Person，但仍保留Leader关联表。从概念上讲，这是一个更好的设计，但由于您可能有一个从组到个人的 CASCADE，因此您将无法在 Leader 上放置双向 CASCADE （如果您尝试，您将收到“多个级联路径”错误）。

是的，我知道这需要更多的工作，并且需要您更加努力地思考您的业务规则是什么，但是相信我，这就是您想要做的。其他任何事情都只会导致痛苦。

Answer 2

最简单的方法如下：

• 在 GroupMember 实体上声明一个布尔属性 IsSelected。
• 向 GroupMember 类添加分部类声明（所有 EF 实体类都声明为分部类，因此可以轻松使用自定义代码扩展它们）。
• 订阅 IsSelected 属性的“BeforeValueChanging”事件（我记不清该事件的确切名称，但您可以确定 EF 提供了类似的内容。） 。
• 然后，您可以在事件处理程序中实现所需的逻辑。无需直接关心数据库...

HTH！