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

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

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