djh*_*262 9 database-design design-patterns anti-patterns associative-table
考虑一个匹配客户端和服务的模型.客户可能在不同时间成为服务的提供者和消费者.客户可以是个人或团体(公司),后者具有多个联系人.联系人可能有多个地址,电话,电子邮件.这些关系中的一些将是一对一的(例如,对提供商的服务),但大多数将是一对多或多对多(公司的多个联系人将具有相同的地址).
在该模型中,通常存在若干关联表,例如,client_contact,contract_addr,contact_phone,contact_email,service_provider,service_consumer等.
假设您为给定服务的使用者发出简单查询联系信息.除了包含数据的六个实体表之外,连接还将引用五个关联表.关于这种查询,当然没有什么特别有趣的 - 我们每天都这样做.
但是我想到了:为什么不能拥有一个包含所有关联的"主"关联表？除了两个PK之外,还需要这个主表具有"关联类型",并且所有PK都需要具有相同的类型(整数,GUID等).
一方面,查询会变得更复杂,因为每个连接都需要指定类型和PK.另一方面,所有联接都将访问同一个表,并且具有适当的indexng和缓存性能可以显着提高.
我假设可能有一种模式(或反模式)描述这种方法,但没有找到任何在线.有人试过吗？如果是这样,它会扩展吗？
您可以提供的任何参考资料将不胜感激.
你所描述的让我想起数据仓库中的事实表。我的理解是，您从一个典型的事务模式开始，用一个表来对每个多对多关系进行建模。然后，为了重构数据以便于进行维度分析，您可以将架构中的部分/所有关系聚合到一个宽表中，其中每一列都是一个键。这可以有效地提前执行所有可能的联接并将它们转储到表中，从而将查询联接的目的从遵循关系转变为获取实体的属性。
不管怎样，我对这些东西的理解很模糊，我的经验实际上为零，但也许你的想法是另一个名称的事实表，使它们对调查有用。