这是一个创建于 2764 天前的主题,其中的信息可能已经有所发展或是发生改变。
题主在上学读书期间学习数据库课程时,涉及到多对多关联的表结构设计都是采用标准化的解决方式,即增加一张关联表用以保存两个实体之间的联系(例如经典的 student / course / student_course_mapping 这样三张表)
然而在实际工作中,发现系统的业务逻辑较为复杂时(实体之间多对多关系的场景比较普遍),数据库中会充斥很多这样的关联表,然后为了实现页面上某个较为复杂的查询操作,往往需要 join 多张表才能满足需求,以学生 /课程的场景为例,为了查询某个班所有学生所选修的课程的详细信息,就至少需要 join 上述三张表,如果页面上需要查询的条件更多,那么还要再 join 更多的表才能满足一次查询要求,这样显然会大大增加 SQL 语句的执行时间,不知道大家在工作中遇到这样的情况,都有什么好的实践方案么?
题主之前也使用过空间换时间的方案,也即把这样多对多的关系拆分成两个一对多的关系,不知道是否存在更优的解决方案?
PS :顺带请教另一个问题,一个页面中如果存在着非常复杂的查询条件,例如需要模糊查询某个人的名字、某个地点,以及其他一些精确检索条件,对于多个模糊搜索(诸如 like '%XXX%')条件如果做优化才能最大程度的保证 SQL 执行性能?
4 条回复 • 2017-03-30 16:31:46 +08:00
|
|
1
buliugu 2017-03-30 15:56:55 +08:00
异常复杂的搜索条件就上 solr 吧,或者 es
|
|
|
2
jimzhong 2017-03-30 16:24:22 +08:00
模糊搜索似乎不是 SQL 的强项。 我也很好奇多个表 Join 怎么优化。
|
|
|
3
awanabe 2017-03-30 16:29:22 +08:00
可以在 mapping 表冗余 a,b 表的数据。 如果 a , b 表更新不多的话, 可以把 a , b 数据存入缓存( redis )中。 到时候只要去对应关系+缓存即可,单表查询会很快。
join 优化,就是在执行的时候, 尽可能不要出现大表 x 大表的全表扫描情况。。这样笛卡尔乘积爆炸。
|
|
|
4
Sharuru 2017-03-30 16:31:46 +08:00
比起性能更注重关系。 通过 ER 图直接生成对应实体 Entity ,使用 ORM 的方法去 get 想要的数据。
至于性能?堆硬件。
|