关系数据库设计中，用中间表好还是直接设定主外键关联好？

有人会对数据库有这样的疑问：

因为大多数的数据库教程上都是告诉你关系数据库如何去创建1：1、1：N和N:M的数据库关系，但我发现很多开源产品中，并没有直接使用关系数据库的关系查询、关系删除等功能，而是直接在代码中对多个表的查询结果进行组合。

这两种方式的优缺点是什么呢？为什么很多项目都选择后者呢？在一个中型以上的项目实践中，我该选择哪种方式，或是两种方式结合使用？

我想：

1，数据表与数据表之间有关联（Relationship）是肯定的，但是不一定要用外键（Foreign Key），为什么？外键本质是一种约束（Constraint），该约束决定了你在增删改查的时候都会有额外开销。【实际上数据库在处理外键的时候估计也是创建一个中间表根据中间表来做关联操作，完成后再删除】

2，“对于 “N对N” 的关系，两个 Model 之间肯定是需要一张中间表的，比如 Student、Class 之间选课关系，是多对多的，肯定需要一张 Enroll 的表来维持，记录两个表的主键（Primary Key），但是不需要在数据库层加外键约束，只需要加两个索引，或作为联合主键。

3，至于查询，尽量不用 JOIN。但是问题是我确确实实是需要知道多个表的信息。
比如我要知道某门课（Class，已知 ID）的信息，同时还有选上该课（Enrolled）的学生信息（Student）。
使用 JOIN ？没问题，我相信你可以写出一个很长的 JOIN 语句。
但是，可能有的地方大概这样实现的（伪代码）：

  
  
getClassInfo(@class_id)
{ SELECT class_col1, class_col2 FROM class WHERE class.id = @class_id }

getStudentInfo(@class_id)
{ SELECT student_col1, student_col2 FROM student WHERE student.id IN (SELECT enroll.student_id FROM enroll WHERE enroll.class_id = @class_id) }

两种方案各有优缺。
后者最大的一个优点是灵活，比如我们引入缓存（Caching）。
一般来说，一个学校 class 数量不多，并且经常被查询，系统可能会引入缓存层（如 memcached、redis）来存放 class 对象。
那么上面的 getClassInfo 其实会变为

   

  
  
{ 
  if(memcached.has(@class_id) != null)
  {
      return memcached.get(@class_id);
  }
  
  //查询数据库（只有 class 表），和上面的 SQL 一样
  memcached.set(@class_id, class_object);
  return class_object;
}