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

Question

“派对模型”是关系数据库设计的“模式”。至少部分涉及在诸如Customer，Employee，Partner等许多实体之间寻找共性，并将其分解为一些更“抽象”的数据库表。

我想了解您对以下内容的看法：

1. 党内模式背后的核心原则和激励力量是什么？
2. 您对数据模型的处方是什么？ （我的位置非常高，在某些方面可能不正确。我一直在使用它的项目，但我正在与另一个专注于其他问题的团队合作。）
3. 您的经历让您有什么感受？你是否使用它，如果是的话，你会再次这样做吗？有什么利弊？
4. 派对模型是否限制了您对ORM的选择？例如，您是否必须删除某些ORM，因为它们不允许域对象和物理数据模型之间存在足够的“抽象层”？

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

感谢。

Answer 1

  

  
1. 党的核心原则和激励力量是什么？   模型？
  

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

  

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

你在上面的说法非常正确，但需要更多细节。您可以想象这样一种情况：数据库中的实体（称之为缔约方）与另一方签订合同，而另一方可能会将工作分包出去。一方可以是雇员，承包商或公司，也可以是缔约方的所有子类。根据我的理解，你会有一个Party表，然后是每个子类的更具体的表，然后可以进一步子类化（Party - ＆gt; Person - ＆gt; Contractor）。

  

  
1. 您的经历让您有什么感受？你有没有用它，如果   所以，你会再这样做吗？是什么   优点和缺点？
  

如果您需要灵活地向系统添加新类型并在开头和开发人员（用户迁移到新级别，雇用其他公司的公司等）中创建您不期望的类型之间的关系，它有其好处。它还为您提供运行单个查询和检索多种类型的方（公司，员工，承包商）的数据的好处。另一方面，您需要添加额外的抽象层来获取实际需要的数据，并在查询特定类型时增加数据库的负载（或至少增加连接数）。如果你的抽象太过分，你可能需要运行多个查询来检索数据，因为复杂性会开始变得不利于可读性和数据库负载。

  

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

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

Answer 2

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

优点：

• Kick-ass水平可扩展性。在您的实体模型中定义5-6个表后，您可以前往海滩并品尝玛格丽塔酒。您可以通过最少的努力虚拟地扩展此数据库。
• 数据库支持您向其投入的任何数据结构。您还可以动态更改数据结构和参与方/实体定义，而不会影响您的应用程序。这非常非常强大。
• 您可以通过添加记录来建模任意数据实体，而不是更改架构。这意味着你可以告别架构迁移脚本。
• 这是程序员的天堂，因为他们编写的代码将定义他们在代码中使用的实际实体，并且没有从Objects到Tables或类似的东西的映射。您可以将Party表视为所选框架的基础对象（System.Object for .NET）

缺点：

• 派对/实体模型永远不能与ORM一起使用，所以忘记使用EF或NHibernate从实体数据库中获取具有语义意义的实体。
• 很多联接。性能调优挑战。这个'con'与你用来定义你的实体的做法有关，但可以肯定的是，你会做更多那些让你在晚上做恶梦的令人费解的查询。
• 更难消费。不熟悉您的业务的开发人员和数据库专业人员将很难适应这些模型公开的实体。由于一切都是抽象的，因此您无法在数据库之上构建图表或可视化，以解释存储给其他人的内容。
• 需要大量数据访问模型或业务规则引擎。基本上，你必须在某些时候完成从数据库中理解你想要什么的工作，而这次你的数据库模型不会对你有所帮助。

如果您正在考虑关系数据库中的聚会或实体架构，您应该看看其他解决方案，如NoSql数据存储，BigTable或KV商店。有一些很棒的产品，有大规模的部署和牵引力，例如MongoDB，DynamoDB和Cassandra，它们是这一运动的先驱。

Answer 3

当我在20世纪80年代早期参与实施这些想法的团队时，它并没有限制我们对ORM的选择，因为那些尚未被发明。

我随时都会依赖这些想法，因为这个特定的项目是我见过的最具说服力的概念证据之一，这是一个“革命性”的想法（当时肯定是这样）。 / p>

它迫使你一无所获。并且它不会阻止你做任何事情（从任何错误，我的意思）。定义自己的信息模型的是你。

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

Answer 4

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

我刚收到我的副本并且它非常好 - 它为您提供了许多数据建模方法的俯视，包括混合上下文角色模式等。它为每种方法都有详细的PRO和CON。

有一种方法可以模拟党派关系和角色的各种利弊。被接受作为答案的问题仅涵盖“派对模型”的一个实例。

例如，在许多方法中，“员工”，“项目经理”等概念都是角色，即派对可以在特定的上下文中播放。我回家后会尽力给你一个更好的细分。

Answer 5

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

Answer 6

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