最近在工作中遇到这样一个问题:多个数据库实体(以下简称“左侧实体”)要同另一实体关联。关于关联表的设计有如下两种方案。(业务背景是,多种实体有同样的权限控制模型)。
方案1:为每个左侧的实体建立一张与另一实体的关联表。
方案2:只建立一个关联表,完成多个实体对另一实体的关联。需要使用额外的字段存储左侧实体类型。
乍一看,两种方式各有优缺点:某一方案的优点即另一方案的缺点,这里只列出缺点。
方案 | 缺点 |
方案1 | a. 需要建立多张关联表 |
方案2 | a. 需要使用额外的字段存储实体类型; b. 在做关联查询的时候“可能”需要引入实体类型信息(如果采用UUID做实体主键,则无此问题)。 c. 关联表较方案1大,可能导致关联查询时速度变慢。 |
貌似两种方案都没有显著的缺点及优势。如果系统统一使用UUID做实体主键,两者的速度差距将只体现在关联表的大小上。从上述分析中,应该得出使用方案1较优的结论。
但是,这是单纯从数据库schema设计分析得出的结论。如果考虑到上层领域模型的设计,方案2更具优势。由于多个实体都与另一实体关联,说明,多个实体都有相同的业务操作-基于另一关联实体的操作。关于方案2性能的优化,可以考虑在数据库或ORM层次做如下处理:
1. 仍旧使用多关联表方案,但是数据映射上,让左侧实体继承相同的父类(如果ORM可以办得到的话)
2. 如果使用一张关联表,在数控库层次基于实体类型对关联表进行分表(partition),降低效率的负面影响。