database-design - "Master"关联表？

Question

考虑一个用于匹配客户和服务的模型。客户在不同时间可能既是服务的提供者又是消费者。客户可以是个人或团体(公司)，后者具有多个联系人。联系人可能具有多个地址，电话，电子邮件。其中一些关系将是一对一的(例如，对提供商的服务)，但大多数将是一对多或多对多的(公司中的多个联系人具有相同的地址)。

在此模型中，通常会存在几个关联表，例如client_contact，contract_addr，contact_phone，contact_email，service_provider，service_consumer等。

假设您针对给定服务的消费者发出简单的查询以获取联系信息。除了包含数据的六个实体表之外，联接还将引用五个关联表。当然，关于这种查询没有什么特别有趣的-我们每天都在做。

但是我想到了:为什么没有一个包含所有关联的“主”关联表？除了两个PK之外，还要求该主表具有“关联类型”，并且所有PK都必须具有相同的类型(int，GU​​ID等)。

一方面，查询将变得更加复杂，因为每个联接都需要指定类型和PK。另一方面，所有联接都将访问同一表，并且通过适当的indexng和缓存性能可以显着提高。

我认为可能存在描述此方法的模式(或反模式)，但尚未在线找到任何内容。有人尝试过吗？如果是这样，是否可以扩展？

您可以提供的任何引用资料将不胜感激。

Answer 1

您所描述的内容使我想起了数据仓库中的事实表。我的理解是，您从一个典型的事务处理模式开始，该模式具有一个表，用于对每个多对多关系进行建模。然后，为了重组数据以便于进行维分析，可以将架构中的一些/所有关系聚合到一个宽表中，其中每一列都是键。这样可以有效地提前执行所有可能的联接，并将它们转储到表中，从而将查询联接的目的从关系跟踪转变为实体的属性。

无论如何，我对这些东西的理解是朦胧的，我的经验实际上是零，但是也许您的想法是另一个名字的事实表，这使它们对于调查很有用。