36

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

我想了解您对以下方面的想法：

  1. 党的模式背后的核心原则和动力是什么？
  2. 它规定你对数据模型做什么？（我上面的那一点水平很高，在某些方面很可能不正确。我一直在使用它的项目中，但我正在与一个专注于其他问题的单独团队合作）。
  3. 你的经历让你有什么感受？你用过吗，如果用过，你会再用吗？有什么好处和坏处？
  4. 派对模型是否限制了您对 ORM 的选择？例如，您是否必须消除某些 ORM，因为它们不允许在您的域对象和您的物理数据模型之间有足够的“抽象层”？

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

谢谢。

4

6 回答 6

25
  1. 党的模式背后的核心原则和动力是什么？

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

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

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

  1. 你的经历让你有什么感受？你用过吗，如果用过，你会再用吗？有什么好处和坏处？

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

  1. 派对模型是否限制了您对 ORM 的选择？例如，您是否必须消除某些 ORM，因为它们不允许在您的域对象和您的物理数据模型之间有足够的“抽象层”？

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

于 2009-04-04T06:15:52.677 回答
12

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

优点：

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

缺点：

  • Party/Entity 模型永远无法与 ORM 很好地配合，因此请忘记使用 EF 或 NHibernate 从实体数据库中获取语义上有意义的实体。
  • 很多加盟。性能调优挑战。这个“骗局”与您用来定义实体的实践相关，但可以肯定地说，您将执行更多那些会让您在晚上做噩梦的令人费解的查询。
  • 更难消费。不熟悉您的业务的开发人员和数据库专业人员将很难适应这些模型所暴露的实体。由于一切都是抽象的，因此您无法在数据库之上构建图表或可视化来向其他人解释存储的内容。
  • Heavy data access models or business rules engines will be needed. Basically you have to do the work of understanding what the heck you want out of your database at some point, and your database model is not going to help you this time around.

If you are considering a party or entity schema in a relational database, you should probably take a look at other solutions like a NoSql data store, BigTable or KV Stores. There are some great products out there with massive deployments and traction such as MongoDB, DynamoDB, and Cassandra that pioneered this movement.

于 2012-09-27T19:20:49.843 回答
2

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

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

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

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

于 2009-06-08T23:56:28.597 回答
1

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

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

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

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

于 2009-05-04T10:31:42.393 回答
0

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

于 2017-09-25T06:13:46.877 回答
-1

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

于 2009-04-04T19:07:41.167 回答