什么是范式和反范式？
范式和反范式的解释，网上有很多例子，不懂的可以去看下，本节重点是介绍他们的优缺点。
例子：“雇员，部门，部门领导的例子”
| EMPLOYEE | DEPARTMENT | HEAD |
|---|---|---|
| Jones | Accounting | Jones |
| Smith | Engineering | Smith |
| Brown | Accounting | Jones |
| Green | Engineering | Smith |
这个schema的问题是修改数据时可能发生不一致。假如Say Brown接任Accounting部门的领导，需要修改多行数据来反映这个变化，这是很痛苦的事并且容易引入错误。如果“Jones”这一行显示部门的领导跟“Brown”这一行的不一样，就没有办法知道哪个是对的。此外，这个设计在没有雇员信息的情况下就无法表示一个部门—如果我们删除所有Accounting部门的雇员，我们就失去了关于这个部门本身的所有记录，要避免这个问题，我们需要对这个表进行范式化，方式是拆分雇员和部门项。拆分以后可以用下面两张表分别来存储雇员表：
| EMPLOYEE_NAME | DEPARTMENT |
|---|---|
| Jones | Accounting |
| Smith | Engineering |
| Brown | Accounting |
| Green | Engineering |
| DEPARTMENT | HEAD |
|---|---|
| Accounting | Jones |
| Engineering | Smith |
这样设计的两张表符合第二范式，在很多情况下做到这一步已经足够好了。然而，第二范式只是许多可能的范式中的一种。当然呢我们不应该使用姓作为主键，因为这既不能保证唯一性，而且用一个很长的字符串作为主键是很糟糕的主意。
范式的优点和缺点
优点：
1. 范式化的更新操作通常比反范式化要快
2. 当数据较好地范式化时，就只有很少或者没有重复数据，所以只需要修改更少的数据。
3. 范式化的表通常更小，可以更好地放在内存里，所以执行操作会更快
4. 很少有多余的数据以为这检索列表数据时更少需要distinct或者group by才能获得一份唯一的部门列表，但是如果部门是一张单独的表，则需要简单的查询这张表就行了。
缺点：
通常需要关联，稍微复杂一些的查询语句在符合范式的schema上都可能需要至少一次关联，也许更多。这不但代价昂贵，也可能使一些索引策略无效。例如，范式化可能将列存放在不同的表中，而这些列如果在一个表中本可以属于同一个索引。
反范式的优点和缺点
反范式化的schema因为所有的数据都在一张表中，可以很好地避免关联。
如果不需要关联表，则对大部分查询最差的情况—–即使表没有使用索引—是全表扫描。当数据比内存大时这可能比关联要快的多。因为这样避免了随机I/O(全表扫描基本上是顺序I/O，但也不是100%的，跟引擎的实现有关。)。单独的表也能使用有效的索引策略。（例子见书籍）
平时工作中，我们通常是将范式和反范式混合使用，相互结合。