实施具有各方角色的“政党模式”的正确方法是什么？答案

【问题标题】：What is the correct way to implement a 'party model' with the various roles that parties play?实施具有各方角色的“政党模式”的正确方法是什么？
【发布时间】：2011-11-10 12:47:06
【问题描述】：

我们正在开发的项目之一正在发展，我们正处于一个可以重新访问现有数据库并花时间“努力做到正确”的阶段。我们正在研究的一件事是数据模型以及我们如何为“各方”建模。到目前为止，我们已经完成了从交易记录中确定客户详细信息的工作，但现在我们想要存储更多详细信息，并希望结合我们拥有的员工、供应商和会员等的通用数据。

每一方都可以是个人或团体，但也可以有一个或多个角色，例如雇主、客户、成员等。我意识到我们模型中的各方如果没有与另一方的关系就不会存在 (员工需要雇主，客户需要购买公司，会员需要俱乐部等），因为我不希望人们添加诸如“雇主-客户”或“会员-分包商”之类的愚蠢关系，所以我现在有一个名为relationship 的表预先定义了哪些角色可以相互配合。我以前从未见过这种情况，我想知道，我们是否走在正确的轨道上？（这是一个简化的 EER 图，显示了我们认为这可能是如何表示的）

我查看了有关派对模式原则的各种文档，但我无法找到任何（开源）示例来说明它在实践中的实际表现。任何人都可以推荐一个源（最好在 MySQL 中）或分享您如何实现它的经验，也许是表结构或应用程序代码？

【问题讨论】：

标签： mysql sql database-design

【解决方案1】：

This SO answer 有一个各方的实现。

Another answer，将这种模式应用到文章和博客文章和故事中可以解释 cmets 中的一些微妙点。

【讨论】：

谢谢 - 我已经阅读了你的一些其他答案，所以这些链接很受欢迎 - 特别是关于 CHECK 约束的提示。我认为您没有看到我将role 与party 分开并使其成为上图中relationship 的特征的任何异常？
通常情况下，要求雇主是组织，员工是个人的要求将从一张表开始，该表有一个对组织表的外键引用（我猜，在您的模型中是“组” )，以及一个对个人表的外键引用。我认为这比将各方之间的所有关系放在一个表中更简单、更容易理解、更容易维护和更容易扩展。事实上，看起来您根本不需要“个人”和“组”表，这可能不是一件好事。
我们现在被困在 MySQL 上，所以看起来 CHECK 约束已经失效，应用程序级验证开始了！不过感谢您的评论 - 这让我开始思考我们是否需要 role 表，因为应用程序已经知道要根据上下文查找哪个子方。顺便说一句，并不要求雇主是一个团体，而雇员是个人等，但知道他们是一个还是另一个很有用。个人和团体与 API 并存，无论如何，该图是对问题的简化。
无论您必须在应用程序级别执行什么相关操作，都应该偶尔在服务器上的“异常查询”中进行测试。我每晚在我的服务器上运行几个；他们检查我们无法在 DDL 中实现的现实约束的异常。并非每个应用程序都会使用您应用程序的代码。（例如 MySQL 命令行。）
仅您的最后一条评论就值 100 本教科书——您不会在任何普通的数据库书籍中阅读像 "real-world constraints that we couldn't implement in DDL" 这样的内容！我已将其标记为已回答。感谢您的意见。