数据模型和查询业务
+--------+ 1 N +------+
| | +--------> | Sub1 |
| | +------+
| |
| | 1 N +------+
| Main | +--------> | Sub2 |
| | +------+
| |
| | 1 N +------+
| | +--------> | SubN |
+--------+ +------+
查询业务: 以动态条件筛选数据,条件即有 Mian 的字段,又有 Sub1 、Sub2 、SubN 的字段。
当前查询逻辑
select MAIN.ID, MAIN.OTHER
from MAIN
where MAIN.MAIN_CONDITON_FIELD=?
and MAIN.ID in (select SUB_1.MAIN_ID from SUB_1 WHERE SUB_1.SUB_1_CONDITION_FIELD = ?)
and MAIN.ID in (select SUB_2.MAIN_ID from SUB_2 WHERE SUB_2.SUB_2_CONDITION_FIELD = ?)
and MAIN.ID in (select SUB_3.MAIN_ID from SUB_3 WHERE SUB_3.SUB_3_CONDITION_FIELD = ?)
注 1: 副表字段再另行做查询补上,此处不讨论 1+N 查询。
注 2: 该查询逻辑,当副表条件筛选出来的
MAIN_ID多的时候,性能严重下降
问
- 即使不考虑性能问题,只是在数据模型设计上,当前查询逻辑是否合理
- 如果当前查询逻辑不合理,正确的逻辑是什么
- 如果单纯从
SQL层面上考虑,如何做性能优化 - 如果再结合整体设计,代码可维护性上的考虑,如何做性能优化
注:
数据模型不可变更;
查询业务不可变更;
不要求单 SQL ;
可以考虑增加专用与查询的辅助表或缓存表;
单纯从程序层面的缓存技术也可以,但要是能长期维护的,即不考虑临时黑科技。