“政党模式”背后的原则和好处是什么？答案

【问题标题】：What are the principles behind, and benefits of, the "party model"?“政党模式”背后的原则和好处是什么？
【发布时间】：2010-10-17 12:33:28
【问题描述】：

“派对模式”是关系数据库设计的“模式”。至少其中一部分涉及找到许多实体之间的共性，例如客户、员工、合作伙伴等，并将其分解到一些更“抽象”的数据库表中。

我想了解您对以下问题的看法：

政党模式背后的核心原则和动力是什么？
它要求您对数据模型做什么？（我上面的内容水平很高，而且在某些方面很可能不正确。我参与过一个使用它的项目，但我正在与一个专注于其他问题的单独团队合作）。
您的经历让您有什么感受？你用过吗，如果用过，你会再用吗？有什么优点和缺点？
派对模型是否限制了您对 ORM 的选择？例如，您是否必须消除某些 ORM，因为它们在您的领域对象和物理数据模型之间没有足够的“抽象层”？

我确信每一个回复都不会解决这些问题中的每一个......但任何涉及其中一个或多个问题的事情都会帮助我做出我面临的一些决定。

谢谢。

【问题讨论】：

标签： sql database-design orm data-modeling

【解决方案1】：

党的核心理念和动力是什么型号？

就我使用它而言，它主要是关于代码重用和灵活性。我们之前在来宾/用户/管理员模型中使用过它，当您需要将用户从一个组移动到另一个组时，它确实证明了它的价值。将此扩展到让组织和公司代表其下的用户，它实际上提供了一种抽象形式，而这种抽象形式并不是 SQL 中特别固有的。

它要求您对数据模型做什么？（我上面的一点是相当高的水平，很可能在某些方面不正确。我一直在使用它的项目，但我是与一个单独的团队合作，专注于其他问题）。

您在上面的部分中非常正确，尽管它需要更多细节。您可以想象这样一种情况，数据库中的一个实体（称为一方）外包给另一方，而另一方可能反过来分包工作。一方可能是员工、承包商或公司，是一方的所有子类。据我了解，您将有一个 Party 表，然后为每个子类提供更具体的表，然后可以进一步细分（Party -> Person -> Contractor）。

您的经历让您有什么感受？你用过吗，如果所以，你会再这样做吗？是什么利弊？

如果您需要灵活地向系统中添加新类型并在您一开始没有预料到的类型和架构之间建立关系（用户移动到一个新的水平，公司雇用其他公司等），它有它的好处.它还为您提供了运行单个查询并为多种类型的各方（公司、员工、承包商）检索数据的好处。另一方面，您正在添加额外的抽象层以获取您实际需要的数据，并且在查询特定类型时增加了数据库上的负载（或至少连接数）。如果您的抽象太过分了，您可能需要运行多个查询来检索数据，因为复杂性将开始对可读性和数据库负载有害。

派对模型是否限制了您对 ORM 的选择？例如，你有没有必须消除某些 ORM，因为他们没有考虑到足够的之间的“抽象层” 域对象和您的物理数据型号？

这是一个我承认有点薄弱的领域，但我发现在应用程序层中使用视图和镜像抽象并没有造成太大的问题。当我想直接读取数据源时，对我来说真正的问题一直是“数据 X 生活在哪里”（对于系统上的新开发人员来说，这也不总是直观的）。

【讨论】：

很棒的反应。谢谢。当您说“应用层中的镜像抽象”时，您的意思是您的领域对象也遵循派对模型模式吗？
是的，这也意味着您必须在两个地方编写逻辑，这会导致明显的同步问题。但是，我使用第三方 ORM 的范围非常有限（尽管我经常使用内部 ORM 工具）

【解决方案2】：

各方模型（也称为实体模式）背后的理念是定义一个数据库，该数据库利用无模式数据库的一些可扩展性优势。参与方模型通过将其实体定义为参与方类型记录来做到这一点，而不是每个实体一个表。结果是一个非常规范化的数据库，只有很少的表，而且对它存储的数据的语义知之甚少。所有这些知识都被推送到代码中的数据访问中。使用派对模型的数据库升级很少甚至没有，因为模式永远不会改变。它本质上是一个美化的键值对数据模型结构，带有一些花哨的名称和一些额外的属性。

优点：

出色的水平可扩展性。一旦在实体模型中定义了 5-6 个表，您就可以去海滩喝玛格丽塔酒。您可以通过最小的努力虚拟地扩展此数据库。
该数据库支持您提供给它的任何数据结构。您还可以在不影响您的应用程序的情况下即时更改数据结构和方/实体定义。这是非常非常强大的。
您可以通过添加记录而不更改架构来对任意数据实体进行建模。这意味着您可以告别架构迁移脚本。
这是程序员的天堂，因为他们编写的代码将定义他们在代码中使用的实际实体，并且没有从对象到表的映射或类似的东西。您可以将 Party 表视为您选择的框架的基础对象（System.Object for .NET）

缺点：

Party/Entity 模型永远无法与 ORM 很好地配合使用，因此请忘记使用 EF 或 NHibernate 从实体数据库中获取语义上有意义的实体。
很多连接。性能调优挑战。这个“骗局”与您用来定义实体的做法相关，但可以肯定地说，您将做更多令人费解的查询，这些查询会给您带来晚上的噩梦。
更难消费。不熟悉您的业务的开发人员和数据库专业人员将很难适应这些模型所暴露的实体。由于一切都是抽象的，因此您无法在数据库之上构建图表或可视化来向其他人解释存储的内容。
需要大量数据访问模型或业务规则引擎。基本上，您必须在某个时候了解您想要从数据库中得到什么，而您的数据库模型这次不会帮助您。

如果您正在考虑关系数据库中的一方或实体模式，您可能应该看看其他解决方案，如 NoSql 数据存储、BigTable 或 KV 存储。 MongoDB、DynamoDB 和 Cassandra 等一些具有大规模部署和吸引力的优秀产品开创了这一运动。

【讨论】：

这根本没有解决可伸缩性问题。数据项之间的关系限制了轻松的可扩展性。这些关系都还在。它们只是没有在模式中表示。这些关系迫使您共同定位数据或执行昂贵的跨服务器查询。架构与否。

【解决方案3】：

当我在 1980 年代初参与实施这些想法的团队时，它并没有限制我们对 ORM 的选择，因为它们还没有被发明出来。

我随时都会求助于这些想法，因为那个特定项目是我见过的关于“革命性”想法（当时肯定是）最令人信服的概念证明之一。

它强迫你一事无成。它不会阻止你做任何事情（我的意思是任何错误）。定义您自己的信息模型的人就是您自己。

各方都有很多共同点。他们有一个名字等等的事实（我们称之为“signaletics”）。他们具有称为“地址”的主要/主要位置的事实。从某种意义上说，他们都参与了业务合同这一事实。

【讨论】：

【解决方案4】：

这是一个庞大的话题，我建议阅读 Len Silverston 和 Paul Agnew 的 The Data Model Resource Book Volume 3 - Universal Patterns for Data Modeling。

我刚收到我的副本，它非常好 - 它为您提供了许多数据建模方法的概览，包括混合上下文角色模式等。它对每种方法都有详细的优点和缺点。

有很多方法可以对政党关系和角色进行建模，所有这些都各有优缺点。被接受为答案的问题仅涵盖“政党模式”的一个实例。

例如，在许多方法中，“员工”、“项目经理”等概念是一方可以在特定上下文中扮演的角色。回到家后，我会尽力为您提供更好的细分。

【讨论】：

【解决方案5】：

根据我的理解，作为一个简单的谈话：Party 建模提供了灵活性，并且需要更多的努力（如 T-sql join 和 ...）来实现。
我还想指出，“使用 Party 建模（序列化/泛化）使您能够拥有 FK-Relation 到其他表”。例如：想想不同类型的用户（管理员、用户、...），它们泛化到 User 表中，您可以在 Authorization 表中包含 UserID。

【讨论】：

【解决方案6】：

我不确定，但派对模式听起来像是泛化-专业化模式的一个特例。搜索“泛化专业化关系建模”发现一些有趣的文章。

【讨论】：