==============
我先举个例子吧
班级，课程，知识点 三张表
课程和班级，一对多关系，一个课程下可能有多个班级，但是一个班级只能对应一个课程
课程和知识点，多对多，一个课程可以有多个知识点，一个知识点可以有多个课程
这种情况该如何设计数据库，三张表加一张relation表，还是加两张relation表？
============================
关于问题
1、不知道这么理解对不对，但在学习的过程中的确发现，按照三范式设计数据库，查询的时候会连接多张表达到查询目的。但我总觉得自己理解错了
2、连接多张表一定是查询效率就下降了么
4、设计时怎么权衡利弊，有无好的文章或blog私房货推荐阅读
来 这里 补补基础知识，认识一下三大范式和反范式，要基于实验的查询效率来做一个权衡。
推荐看一下《SQL反模式》
https://book.douban.com/subject/6800774/
首先，一个设计良好的数据库，即使连接很多张表，查询效率也几乎不会下降。只不过开发起来有些麻烦，要不停的去联表或填充数据。
如果不遵守第三范式，当数据经常更新的时候，就会很麻烦，要改很多地方。而不经常修改的表，比如报表和日志记录，字段很多，生成一次一般就不会再修改了，那么可以做数据冗余，满足第二范式即可。
- 是
- 很可能是，索引不利的时候更甚
- 这个问题不是一篇文章乃至一本书就能说完的，只能带着这个意识多实践多总结多思考
经历几次业务从小到大，或是需求迭代，或是设计不合理导致数据结构崩溃 慢慢就明白了
一定程度上看需求 比如多个流程互相关联 A变了 B中A的信息不是立刻变而是需要确认什么的
又或者需求高效率 那么就数据冗余一下(比如消息、通知等等)
一般来说 按范示走 (不然很可能就成为坑了
<<SQL反模式>>这书不错 推荐看看
节省空间和增加查询效率之间,有时候是存在矛盾的.
很多时候都需要进行取舍.
其实这样的时候可以适当的反范式设计表.按照实际的需要适当增加一些重复的字段到一张表上是有好处的.
我有时会这样做.
但同时也有些问题,如果需求变了那就可能悲剧. 好的情况是这个冗余字段没用了.坏情况就是可能要修改表字段.
如果这时表已经积累非常多的数据,那就异常痛苦.
我一般倾向如果表列不是特别多的时候尽量增加些冗余吧!
也不用太纠结,实践证明除非数据一张表过了几千万,否则不会有太大的性能影响.
没必要想太多了. 真正需要优化的场景很少的.
数据库是要注重效率,但绝对没想象中那么脆弱.
一般慢的原因都是本身配置不合理,程序逻辑不合理,或者索引加的不合理引起的.真正什么高并发或者大量数据的情况真的很难遇到,你放心用就行了.