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

Question

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

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

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

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

谢谢.

Answer 1

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

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

2. 它对您的数据模型有何规定？(我的位置相当高,在某些方面可能不正确.我一直在使用它的项目,但我正在与另一个专注于其他问题的团队合作).

虽然它需要更多细节,但你在上面的说法非常正确.您可以想象一种情况,即数据库中的实体(称之为缔约方)与另一方签订合同,这可能反过来将合同分包出去.一方可以是员工,承包商或公司,也可以是缔约方的所有子类.根据我的理解,你会有一个Party表,然后是每个子类的更具体的表,然后可以进一步子类化(Party - > Person - > Contractor).

3. 您的经历让您有什么感受？你是否使用它,如果是的话,你会再次这样做吗？有什么优点和缺点？

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

4. 派对模型是否限制了您对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,它们是这一运动的先驱.