1 数据库设计的三大范式
第一范式：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。
第二范式：第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。这个唯一属性列被称为主关键字或主键、主码。
第三范式：满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的；同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。
2 通俗理解
说这么多也就是减少冗余，减少空间，但是这样性能就下降了，其实范式只是为了可以为你理清数据库的关系的，但是有些情况采用范式的代价要比不采用范式的代价大就可以不适用范式。比如增加了程序逻辑，多联接关系表，不常更新或不更新的基础表信息都可以不必须按照范式的规范来设计。
3 对于现在还需要吗？
对于现在的大多数项目，发展的后期，性能瓶颈都出现在了数据库上，然而在数据库上做优化的空间非常小，相反，在应用上做优化的空间就大多了，比如集群，分布式，缓存等等，可以轻易地把计算压力分解到n台服务器上。对于空间也不是很需要珍惜，对于现在的高并发，如果关联性太强很容易造成奔溃，所以我倾向于去掉所有的关联，为了开发的方便。然后写代码的时候自己留意完整性的问题。
4 冗余设计
头条项目全部采用逻辑关联，没有采用主外键约束。也是方便数据源冗余，尽可能少的使用多表关 联查询。冗余是为了效率，减少join。单表查询比关联查询速度要快。某个访问频繁的字段可以冗余存 放在两张表里，不用关联了。
如查询一个订单表需要查询该条订单的用户名称，就必须join另外用户表，如果业务表很大，那么就会 查询的很慢，这个时候我们就可以使用冗余来解决这个问题，在新建订单的同时不仅仅需要把用户ID存储，同时也需要存储用户的名称，这样我们在查询订单表的时候就不需要去join另外用户表，也能查询出该条订单的用户名称。这样的冗余可以直接的提高查询效率，单表更快。(空间换时间,浪费空间但是时间节省了.空间现在多的是)
5 单表查询和多表连接查询哪个效率更快
一.第一个解答来源于《高性能Mysql》中的回答
很多高性能的应用都会对关联查询进行分解。简单地，可以对每个表进行一次单表查询，然后将结果在应用程序中进行关联。例如，下面这个查询：
select * from tag
join tag_post on tag_post.tag_id=tag.id
join post on tag_post.post_id=post.id
where tag.tag=’mysql’;
可以分解成下面这些查询来代替：
Select * from tag where tag=’mysql’;
Select * from tag_post where tag_id=1234;
Select * from post where id in(123,456,567,9989,8909);
到底为什么要这样做？
咋一看，这样做并没有什么好处，原本一条查询，这里却变成了多条查询，返回结果又是一模一样。
事实上，用分解关联查询的方式重构查询具有如下优势：（高并发、高性能的应用中，一般建议使用单表查询）
1. 让缓存的效率更高。
许多应用程序可以方便地缓存单表查询对应的结果对象。另外对于MySQL的查询缓存来说，如果关联中的某个表发生了变化，那么就无法使用查询缓存了，而拆分后，如果某个表很少改变，那么基于该表的查询就可以重复利用查询缓存结果了。
2. 将查询分解后，执行单个查询可以减少锁的竞争。
3. 在应用层做关联，可以更容易对数据库进行拆分，更容易做到高性能和可扩展。
4. 查询本身效率也可能会有所提升。
5. 可以减少冗余记录的查询。
6. 更进一步，这样做相当于在应用中实现了哈希关联，而不是使用MySQL的嵌套环关联，某些场景哈希关联的效率更高很多。
7. 单表查询有利于后期数据量大了分库分表，如果联合查询的话，一旦分库，原来的sql都需要改动。
8. 上次看到某个CTO技术分享，公司规定底层禁止用join联合查询。数据大的时候确实慢。
9. 联合查询或许确实快，但是mysql的资源通常比程序代码的资源紧张的多。
二.其他回答
情景假设：假设网站有一个公司库版块，我想搜索某城市的所有公司。
数据表：tbl_company （t1）、 tbl_city (t2)。
例1： t1表中存cityid 根据id做表连接查询 select * from t1 inner join t2 on t1.cityid=t2.cityid;
例2： t1表中存cityName 用户前台点击上海市，则把上海市的id传到后台（不考虑传cityName），根据id查出cityName select cityName from t2 where cityid= #{cityid};， 然后 select * from t1 where cityName = #{cityName};
两者区别：例1中只做了一次表关联查询，例2中分别做了两次单表查询。
考虑到数据量大，多表连接查询会影响查询效率所以都优化为单表查询。 TP：以上是在不使用索引的情况下
请问哪种效率会更高些?
答：sql优化与业务也有关系，这条语句的查询会不会频繁，要不要考虑2次连接带来的开销，如果这些都不用考虑的话，都没有索引的情况下，感觉相差不大，2应该略优于1。
数据没有特别大的情况还是级联查询快。
对于传统的数据库涉及来说, 尽可能减少数据库查询次数.
BUT, 1. mysql都对处理连接/断开连接, 回复小而简单的 查询是非常快的; 2.现在的网络已经非常快了. 所以多个小的查询对mysql来说可能更快一些.
最后, 大神也没有结论哪个更好. 呵呵, 其实整本书都明确表达一个意思, 测试测试! 做benchmark! 对于自己的数据环境, 把两种方式都测试一下. 用数据说话.
总结：建议还是用单表查询！
