大家在工作中遇到多对多实体关系时的表结构都是如何设计的？

[jayn1985]

题主在上学读书期间学习数据库课程时，涉及到多对多关联的表结构设计都是采用标准化的解决方式，即增加一张关联表用以保存两个实体之间的联系（例如经典的 student / course / student_course_mapping 这样三张表）
然而在实际工作中，发现系统的业务逻辑较为复杂时（实体之间多对多关系的场景比较普遍），数据库中会充斥很多这样的关联表，然后为了实现页面上某个较为复杂的查询操作，往往需要 join 多张表才能满足需求，以学生 /课程的场景为例，为了查询某个班所有学生所选修的课程的详细信息，就至少需要 join 上述三张表，如果页面上需要查询的条件更多，那么还要再 join 更多的表才能满足一次查询要求，这样显然会大大增加 SQL 语句的执行时间，不知道大家在工作中遇到这样的情况，都有什么好的实践方案么？
题主之前也使用过空间换时间的方案，也即把这样多对多的关系拆分成两个一对多的关系，不知道是否存在更优的解决方案？

PS ：顺带请教另一个问题，一个页面中如果存在着非常复杂的查询条件，例如需要模糊查询某个人的名字、某个地点，以及其他一些精确检索条件，对于多个模糊搜索（诸如 like '%XXX%'）条件如果做优化才能最大程度的保证 SQL 执行性能？

[buliugu]

异常复杂的搜索条件就上 solr 吧，或者 es

[jimzhong]

模糊搜索似乎不是 SQL 的强项。
我也很好奇多个表 Join 怎么优化。

[awanabe]

可以在 mapping 表冗余 a,b 表的数据。
如果 a ， b 表更新不多的话， 可以把 a ， b 数据存入缓存（ redis ）中。
到时候只要去对应关系+缓存即可，单表查询会很快。

join 优化，就是在执行的时候， 尽可能不要出现大表 x 大表的全表扫描情况。。这样笛卡尔乘积爆炸。

[Sharuru]

比起性能更注重关系。
通过 ER 图直接生成对应实体 Entity ，使用 ORM 的方法去 get 想要的数据。

至于性能？堆硬件。