SQL数据库中各类实体名称应存储于单张大表还是多张小表？

问题背景 #

现有数据库包含10+张主表（例如books、authors、publishers、distributors、artists、characters等）和大量关联表。每个实体可能存在多个名称，既包括不同语言的版本，也包括同语言下的多个别名，数量不确定，无法通过在主表新增多列的方式存储。

已梳理的可选方案 #

• 方案1：每个主表对应一张独立的名称表，关联主表ID字段。该方案可正常运行，但存在10+张结构、约束完全一致的名称表，复用性差，调整约束或字段规则需要修改多处，新增主表时也要同步新增名称表。
• 方案2：统一使用单张names大表，新增字段标识所属表类型，存储所有实体的名称。该方案结构更简洁，但无法通过varchar类型的表名字段建立外键约束，缺少数据完整性校验。
• 方案3：将所有业务主表合并为通用的Items或Things表，统一ID规则后关联单张名称表，可正常使用外键约束。但该方案表语义模糊，无法直接区分实体类型，关联逻辑极易出错。
• 方案4：主表新增单个长文本字段，按固定格式存储多语言名称（例如eng:Donald Duck, fre:Donald, nor:Anders And, swe:Kalle Anka），无需关联查询但读取时需要额外解析字符串。

现存权衡顾虑 #

目前在方案1和方案2之间权衡：单张名称表结构更整洁，也更便于全局搜索，但担心大表数据量增长后查询性能下降，尤其是多关联查询场景下需要多次检索名称表。
假设每个类型有1000个实体，平均每个实体对应2个名称，小表方案仅需要从2000行数据中执行查询：

SELECT NAME FROM BOOK_TITLES WHERE ID=? AND LANG=?

而单表方案需要从20000行甚至更多数据中执行查询：

SELECT NAME FROM NAMES WHERE TYPE='BOOK' AND ID=? AND LANG=?

同时由于同一实体同语言下可存在多个名称，无法将TYPE+ID+lang设为主键，担心大表检索效率低下。

最优解决方案 #

首推优化后的单表方案（方案2变体），可以同时解决你担心的性能和完整性问题：

• 性能问题解决：你提到的2万行级数据量根本算不上“大表”，哪怕后续增长到百万级，只要给names表建立(type, entity_id, lang)的联合前缀索引，你写的查询语句刚好完全命中索引，不需要全表扫描，查询效率和小表方案没有任何区别，甚至因为索引缓存命中率更高，性能会比多小表更好。即使同实体同语言有多个别名，最多就是多返回几行结果，对性能没有影响。
• 完整性问题解决：新增一张entity_types字典表，存储所有主表的唯一类型标识（比如type_id int主键，type_name varchar存储对应主表名），将names表的type字段改为int类型关联entity_types的主键，避免非法类型值写入。如果需要更严格的关联ID存在性校验，要么加数据库触发器做校验，要么在应用层的公共写入方法里加校验逻辑，足够覆盖99%的脏数据场景。
• 维护优势：后续新增实体类型只需要给entity_types表加一行记录，不需要新增表，调整字段规则也只需要改一次names表，全局搜索名称也不需要跨十多张表做union查询，便利性比方案1高太多。

如果你的业务对数据一致性有极致要求，不能接受应用层/触发器校验，就选方案1，配合ORM的模型继承或者代码生成工具自动生成所有名称表的结构和CRUD代码，也能抵消大部分重复维护的成本，性能也完全够用。

内容的提问来源于stack exchange，提问作者Zimeon