“党模式”背后的原则和好处是什么？
“党模式”是关系数据库devise的“模式”。 其中至less有一部分涉及许多实体（如客户，员工，合作伙伴等）之间的共同性，并将其分解到一些更为“抽象”的数据库表中。
我想找出你的想法如下：
- 党模式背后的核心原则和激励力量是什么？
- 它对你的数据模型做了什么规定？ （我的上面是相当高的水平，在某些方面很可能是不正确的，我一直在使用它的项目，但我正在与一个专注于其他问题的单独的团队合作）。
- 你有什么经验让你感觉到这一点？ 你有没有使用它，如果是的话，你会再这样做吗？ 有什么优点和缺点？
- 派对模特是否限制了您select的ORM？ 例如，您是否必须消除某些ORM，因为它们不允许在域对象和物理数据模型之间build立足够的“抽象层”？
我相信每一个答案都不会解决这些问题中的每一个……但是任何涉及其中一个或多个问题的东西都将帮助我做出我正在面对的一些决定。
谢谢。
- 党模式背后的核心原则和激励力量是什么？
就我使用它而言，主要是关于代码重用和灵活性。 我们之前在guest / user / admin模型中使用过它，当您需要将用户从一个组移到另一个组时，它肯定会certificate它的价值。 把它扩展到让组织和公司代表下面有用户的组织，这实际上提供了一种抽象forms，这在SQL中并不是特别固有的。
- 它对你的数据模型做了什么规定？ （我的上面是相当高的水平，在某些方面很可能是不正确的，我一直在使用它的项目，但我正在与一个专注于其他问题的单独的团队合作）。
你在上面是非常正确的，虽然它需要更多的细节。 您可以想象一下，数据库中的一个实体（称为“缔约方”）将合同外包给另一方，然后再转包出去。 一方可能是一个雇员，一个承包商，或一个公司，所有党的子类。 根据我的理解，你会有一个党的表，然后为每个子类更具体的表，然后可以进一步子类（党 – >人 – >承包商）。
- 你有什么经验让你感觉到这一点？ 你有没有使用它，如果是的话，你会再这样做吗？ 有什么优点和缺点？
如果您需要灵活地向您的系统添加新types，并在创build者和架构师（用户移动到新的级别，雇用其他公司等的公司等）期间创buildtypes之间的关系，则它有其好处。 它还为您提供运行单个查询和检索多种types的参与方（公司，员工，承包商）的数据的好处。 另一方面，您要添加额外的抽象层以获取您实际需要的数据，并且在查询特定types时正在增加数据库的负载（或至less是连接数）。 如果您的抽象过度，您可能需要运行多个查询来检索数据，因为复杂性将开始变得不利于可读性和数据库负载。
- 派对模特是否限制了您select的ORM？ 例如，您是否必须消除某些ORM，因为它们不允许在域对象和物理数据模型之间build立足够的“抽象层”？
这是我承认有点弱的一个领域，但我发现在应用层使用视图和镜像抽象并没有造成太多的问题。 当我想要直接读取数据源时（对于系统中的新开发人员来说，这并不总是直观的），对我来说，真正的问题一直是“数据生活在哪里”。
聚会模型（又名实体模式）背后的思想是定义一个数据库，它利用了无模式数据库的一些可伸缩性优点。 聚会模型通过将其实体定义为聚会typeslogging来实现，而不是每个实体一个表。 结果是一个非常规范化的数据库，只有很less的表格，而且对存储的数据的语义含义知之甚less。 所有这些知识都被推送到代码中的数据访问。 使用派对模型的数据库升级是最小的，因为模式不会改变。 它本质上是一个荣耀的键值对数据模型结构，有一些奇特的名字和一些额外的属性。
优点：
- 踢屁股水平伸缩性。 一旦您的实体模型中定义了5-6表格，您可以去海滩和啜饮玛格丽塔酒。 您可以通过尽可能less的努力来尽可能多地扩展这个数据库。
- 该数据库支持你抛出的任何数据结构。 您也可以即时更改数据结构和聚会/实体定义，而不会影响您的应用程序。 这是非常非常强大的。
- 您可以通过添加logging来build模任何任意数据实体，而不是更改模式。 这意味着你可以告别模式迁移脚本。
- 这是程序员的天堂，因为他们编写的代码将定义它们在代码中使用的实际实体，并且没有从对象到表或类似的东西的映射。 您可以将Party表视为您所选框架的基础对象（System.Object for .NET）
缺点：
- Party / Entity模型从来没有和ORM一起玩，因此忘记使用EF或NHibernate从实体数据库中获取语义上有意义的实体。
- 很多连接。 性能调整挑战。 这个“con”与你用来定义你的实体的做法有关，但是可以肯定地说，你将会做更多的那些令人费解的查询，在晚上给你带来恶梦。
- 更难消费。 不熟悉业务的开发人员和数据库专业人员将很难习惯这些模型公开的实体。 因为一切都是抽象的，所以没有图表或可视化，你可以build立在数据库之上来解释存储给别人的东西。
- 需要大量的数据访问模型或业务规则引擎。 基本上你必须做一些工作来理解你想从数据库中得到什么，而这个时候你的数据库模型不会帮你。
如果您正在关系数据库中考虑派对或实体模式，您可能应该看看其他解决scheme，如NoSql数据存储，BigTable或KV商店。 这里有一些非常棒的产品，如MongoDB，DynamoDB和Cassandra这样的大规模部署和牵引。
当我在20世纪80年代早期实现这些想法的时候，并没有限制我们对ORM的select，因为那些还没有被发明出来。
任何时候我都会回头看这些想法，因为那个特定的项目是我所见过的一个“革命”的想法（当时当然是这样）最有说服力的概念certificate之一。
它迫使你什么也没有。 而且它不阻止你从任何东西（我的意思是任何错误）。 定义你自己的信息模型的就是你。
各方都有很多共同的特性。 他们有一个名字和这样的事实（我们称之为“signaletics”）。 他们有主要/主要地点的事实称为“地址”。 事实上，他们都在某种意义上涉及到企业的合同。
这是一个很大的话题，我推荐阅读Len Silverston和Paul Agnew的“数据模型资源手册第三卷 – 数据build模的通用模式” 。
我刚收到我的副本，这很好 – 它为您提供了许多数据build模方法，包括混合上下文angular色模式等等。 每种方法都有详细的PRO和CON。
有各种各样的方法来模拟党的关系和angular色的利弊。 被接受为答案的问题只包含一个“派对模式”的例子。
例如，在许多方面，“员工”，“项目经理”等概念都是一方在特定环境下可以发挥的作用 。 一旦我回家，我会尽力给你一个更好的分解。
我不确定，但派对模式听起来像泛化专业化模式的一个特例。 search“泛化专业化关系build模”find一些有趣的文章。
作为一个简单的谈话，从我的理解：党build模给予的灵活性，需要更多的努力（如T – SQL的join和…）来实施。
我也想指出，“使用Partybuild模（序列化/泛化）使您能够将FK关联到其他表格”。 例如：考虑不同types的用户（pipe理员，用户，…），这些User表一般化到User表中，并且您可以在Authorization表中拥有UserID 。
