范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。数据库的设计范式是数据库设计所需要满足的规范。只有理解数据库的设计范式，才能设计出高效率、优雅的数据库，否则可能会设计出错误的数据库。

反范式，不满足范式的模型，就是反范式模型。反范式跟范式所要求的正好相反，在反范式的设计模式，我们可以允许适当的数据的冗余，用这个冗余去取操作数据时间的缩短。本质上就是用空间来换取时间，把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联。

RDBMS 模型设计过程中，常常使用范式约束我们的模型，但在 NOSQL 模型中则大量采用反范式。

数据库中范式和反范式的的主要区别在于：

Java学习笔记：数据库中的范式和反范式

在范式化的数据库中，每个事实数据会出现并且只出现一次；相反，在反范式化的数据库中，信息是冗余的，可能会存储在多个地方。

范式化的优点：

1）范式化的更新操作通常比反范式化要快。

2）当数据较好地范式化时，就只有很少或者没有重复数据，所以只需要修改更少的数据。

3）范式化的表通常更小，可以更好地放在内存里，所以执行操作会更快。

4）很少有多余的数据意味着检索列表数据时更少需要DISTINCT或者GROUP BY语句。

范式化设计的 schema 的缺点是通常需要关联，较多的关联可能使得一些 索引 策略无效，例如，范式化可能将列存放在不同的表中，而这些列如果在一个表中本可以属于同一个索引。

反范式的schema因为所有数据都在一张表中，可以很好地避免关联。缺点是update操作的代价高，需要更新多个表，至于这会不会是一个问题，需要考虑更新的频率以及更新的时长，并和执行select查询的频率进行比较。

从另一个父表冗余一些数据到子表的理由通常是排序的需要。

缓存 衍生值也是有用的。如果需要显示每个用户发了多少消息（像很多论坛做的），可以每次执行一个昂贵的子查询来计算并显示它；也可以在user表中建一个num_messages列，每当用户发新消息时更新这个值。