设置项参数存储方案对比：独立参数表与合并单参数表哪个更优？

优化方案的固有缺陷 #

你设想的参数组合中间表方案确实存在几个难以规避的固有问题：

• 组合爆炸风险：参数数量和各参数的取值越多，参数表需要存储的组合数就会呈指数级增长。比如3个参数各有10种取值，最多需要存1000条组合；新增第4个10取值的参数，组合数直接涨到10000条，其中还包含大量为了适配不同设置项的NULL值无效组合，数据膨胀速度完全不可控。
• 查询逻辑复杂易出错：不同设置项的依赖参数不同，查询时需要额外判断不相关参数是否为NULL，比如查hardware settings时要加参数表.session_type_id IS NULL的条件，每个设置项的查询逻辑都不统一，很容易写出漏条件的BUG。
• 数据一致性维护成本高：很容易出现重复的参数组合记录，关联设置表时会返回重复的设置结果；删除某类参数值时，需要先清理所有关联该值的组合记录，再清理对应设置记录，操作链路长，容易出现孤立垃圾数据。
• 性能损耗：每次查询设置都要多关联一层中间表，对比原方案直接查设置表的逻辑，查询效率会有明显下降。

两种方案的优缺点对比 #

原方案（各设置表单独存依赖参数字段） #

优点：

• 逻辑清晰直观：需要什么参数就加什么字段，不需要的完全不用管，查询直接走等值匹配，几乎不会出逻辑错误。
• 性能优异：直接给每个设置表加对应依赖参数的联合索引，比如hardware settings表加(device_id, computer_id)联合索引，查询速度非常快。
• 一致性易维护：各参数字段直接关联对应主表的外键，依靠数据库外键约束就能处理删改的一致性问题，没有额外中间数据需要维护。
  缺点：
• 新增全局参数时需要逐个修改关联的设置表加字段，比如新增user_id参数有5个设置项需要依赖，就要改5张表。
• 不同设置表会有重复的参数字段，比如多张表都有device_id列，但这个属于逻辑必要的重复，不是无效冗余。

优化的中间参数组合表方案 #

优点：

• 新增参数时只需要修改参数组合表加字段，不需要修改各个设置表，新增全局参数的改表次数更少。
• 所有参数组合统一存储，需要全局统计参数组合的场景下更方便。
  缺点就是前面提到的固有缺陷，整体维护成本远高于原方案。

推荐方案 #

绝大多数场景下更推荐用原方案：
如果你的参数新增频率很低（比如半年以上才会加一个新的全局参数），原方案的缺点影响可以忽略，逻辑简单、性能好、维护成本低的优势会非常突出，完全够用。
如果确实参数新增频率极高（比如每月都要加新参数），也不建议用你这个中间参数组合表的方案，可以改用更灵活的键值对存储结构：设置表存设置项类型、参数键、参数值、设置内容，用行存储的方式存参数，灵活度更高，也不会有组合爆炸的问题。

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