多个数据库实体与另一实体使用一张表关联的问题 – 分析篇

最近在工作中遇到这样一个问题：多个数据库实体（以下简称“左侧实体”）要同另一实体关联。关于关联表的设计有如下两种方案。（业务背景是，多种实体有同样的权限控制模型）。

 

方案1：为每个左侧的实体建立一张与另一实体的关联表。

方案2：只建立一个关联表，完成多个实体对另一实体的关联。需要使用额外的字段存储左侧实体类型。

 

乍一看，两种方式各有优缺点：某一方案的优点即另一方案的缺点，这里只列出缺点。

 

方案	缺点
方案1	a.       需要建立多张关联表
方案2	a.       需要使用额外的字段存储实体类型； b.       在做关联查询的时候“可能”需要引入实体类型信息（如果采用UUID做实体主键，则无此问题）。 c.        关联表较方案1大，可能导致关联查询时速度变慢。

 

貌似两种方案都没有显著的缺点及优势。如果系统统一使用UUID做实体主键，两者的速度差距将只体现在关联表的大小上。从上述分析中，应该得出使用方案1较优的结论。

 

但是，这是单纯从数据库schema设计分析得出的结论。如果考虑到上层领域模型的设计，方案2更具优势。由于多个实体都与另一实体关联，说明，多个实体都有相同的业务操作-基于另一关联实体的操作。关于方案2性能的优化，可以考虑在数据库或ORM层次做如下处理：

 

1.       仍旧使用多关联表方案，但是数据映射上，让左侧实体继承相同的父类（如果ORM可以办得到的话）

2.       如果使用一张关联表，在数控库层次基于实体类型对关联表进行分表（partition），降低效率的负面影响。