重复相似SQL查询是否违反DRY原则？求最优实现方案

问题背景 #

项目中存在仅表名不同的相似SQL查询，示例如下：

-- 两个独立查询
select t1.mycolumn
from tb_america t1 -- 唯一差异：表名
inner join table2 t2 on t1.field = t2.field
inner join table3 t3 on t3.field = t2.field

select t1.mycolumn
from tb_asia t1 -- 唯一差异：表名
inner join table2 t2 on t1.field = t2.field
inner join table3 t3 on t3.field = t2.field

-- 或者参数化表名的写法
@varcountry = param ? 'tb_asia' : 'tb_america';

select t1.mycolumn
from @varcountry t1
inner join table2 t2 on t1.field = t2.field
inner join table3 t3 on t3.field = t2.field

当前采用拆分两个独立查询的方式，疑问是否违反DRY原则；若改用参数化表名，又担心后续单查询变更会导致代码混乱、违反KISS原则，且无法修改客户数据库表结构，寻求合理处理方案。

解决方案分析 #

1. 拆分独立查询：不违反DRY，更贴合KISS #

拆分两个独立查询的做法并不违反DRY原则——DRY的核心是避免重复的业务逻辑，而非完全杜绝相似代码。当两个查询仅表名不同，但后续可能各自有独立的业务调整需求时，拆分写法优势明显：

• 每个查询意图清晰，维护时直接定位对应表的查询即可，无需额外理解参数化的分支逻辑
• 若后续其中一个查询需要调整字段、过滤条件或关联规则，不用担心影响另一个查询，降低变更风险

2. 参数化表名：适合长期无差异化变更的场景 #

如果可以确定这两个查询长期不会有独立变更（比如业务规则完全一致，仅数据按区域分表存储），参数化表名是更符合DRY的选择，但要做好可读性优化：

• 用清晰的变量名（比如@region_table）明确表名含义，避免模糊命名
• 在参数化代码旁添加注释，标注对应表名的业务场景，方便后续维护者理解
• 若数据库支持，可封装成存储过程，减少应用层的重复代码

3. 折中方案：用视图统一逻辑（若客户允许创建视图） #

虽然无法修改原表结构，但如果客户允许创建视图，可以通过视图封装公共关联逻辑，再针对不同表做简单查询：

-- 创建视图封装公共关联逻辑，手动添加区域标识
create view vw_mycolumn_query as
select t1.mycolumn, 'america' as region
from tb_america t1
inner join table2 t2 on t1.field = t2.field
inner join table3 t3 on t3.field = t2.field
union all
select t1.mycolumn, 'asia' as region
from tb_asia t1
inner join table2 t2 on t1.field = t2.field
inner join table3 t3 on t3.field = t2.field;

-- 业务查询时仅需过滤区域
select mycolumn from vw_mycolumn_query where region = 'america';
select mycolumn from vw_mycolumn_query where region = 'asia';

这种方式既统一了公共关联逻辑（符合DRY），又保留了独立查询的清晰性（符合KISS），但前提是客户允许创建视图。

总结 #

• 若两个查询未来可能独立变更：保留拆分的独立查询，这是最符合KISS的选择，且不违反DRY（本质是针对不同业务实体的查询）
• 若两个查询长期逻辑一致：采用参数化表名，但要做好注释和可读性优化
• 若允许创建视图：用视图封装公共逻辑，兼顾DRY和KISS

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