22丨反范式设计：3NF有什么不足，为什么有时候需要反范式设计？

一言以蔽之：反范式无处不在。😃 最近正在基于Hadoop建设某国企的数据集市项目（地域性非全网），恰如老师所言，我们就是在遵循反范式的设计。 简要来说，我们把数据加工链路分为四层，从下到上依次为：ODS贴源层、DWD明细层、DWS汇总层和ADS应用层。 多源异构的业务数据被源源不断ETL到ODS贴源层之后，经过清洗、规范、转换、拼接等，生成各类宽表存储在DWD明细层；再根据业务模型设计，以这些宽表为基础，生成各类标准的指标数据存储在DWS汇总层；ADS层则基于DWS层的汇总指标再度组合，计算得出应用层数据，直接面向业务需求。 在这样的系统设计中，反范式不仅体现在“宽表”的设计中，更体现在数据加工链路的完整生命周期中——上层都是对下层的冗余。

个人对于反范式的理解是：它会造成数据的冗余甚至是表与表之间的冗余；不过它最大的好处是减少了许多跨表查询从而大幅减少了查询时间。早期的设计其实一直强调范式化设计，可是当memcache出现后-其实就反向在揭示范式的不足。 互联网行业和传统行业最大的区别是要求相应时间的短暂：这就造成了效率优先，这其实也是为何互联网行业的技术更新和使用走在最前面。曾经经历过设计表的过程中尽力追求范式，可是最终发现带来的问题就是性能的不足；范式其实就是规范，可是完完全全的规范-碰到特殊场景就不能那样使用。10年前接触到非关系型数据库时就引发了这种思考，sql server和mysql的机制和查询特长的不同更加引发了自己对于范式的反思。 其实不同数据库对于范式的操作应当是不同的不同行业对于效率的要求是不同的：我觉得范式与反范式的关系可能有点像现在关系型数据库和非关系型数据库的使用一样，已经不再是单一化，如何让二者合理结合最大发挥数据库的查询效率才是关键-只有最合适的没有最好的；当我们过度的追求标准化时反而会忽视了产品真实的功能者作用，如何充分合理发挥产品性能其实才是我们所追求的。 老师觉得呢：没有最标准的，任何方式都有缺陷，没有最好的只有最合适的；就像Google 的SRE中有句经典的话“没有问题的程序是程序的特殊状态”。

这个数据集都是百万条记录的，如果直接导入MySQL比较慢。如果先做以下设置会大大提高导入的速度： SET GLOBAL unique_checks=0; SET GLOBAL innodb_flush_log_at_trx_commit=0; SET GLOBAL sync_binlog=0; 当然这不是SQL的问题，是数据库工作方式的问题，不在本课讨论范围内，只是提供大家参考，节省准备的时间。 导入完成以后记得把所有设置都改回1。

反范式注意好同步。

请问老师，冗余字段的更新有哪些方式啊？文中只是提到存储过程更新冗余字段

范式与反范式，正如传统与解构，规则与务实，稳定与突破，守成与创新，是阴阳动静的矛盾关系，两者一而二，二而一，即和而不同、求同存异，落脚点是务实，也就是应用场景和业务需求。 所以说，这已经不单是数据库设计的问题，而中国哲学体系在互联网商业中实践指导。 数据库设计提出范式的同时存在反范式的要求，符合否定之否定的螺旋上升轨迹，是数据库也是SQL语言保持强壮生命力而经久不衰的重要原因，是现实生存逻辑的映射。

老师您好，想问个问题；假设我在存储过程中，用到了一个临时表（作用就是保存中间数据以便后续做其他操作），先对临时表进行数据删除操作，然后对临时表进行插入操作。假设现在有两个人A,B同时调用该存储过程，是否存在如下风险，即：A执行存储过程时，正在删除数据，同一时刻，B执行存储过程时，新增数据？

olap可以用反范式，但oltp就不适合了，实时的交易和数据变化，反范式的空间换时间不适合

“”“在这里，主属性是包含在任一候选键中的属性，也就是仓库名，管理员和物品名。非主属性是数量这个属性。” 老师你你说的这句话我有点问题，按理说我们如果默认仓库名和物品名是候选键的话，那管理员就是非主属性， 候选键的一部分，也就是说仓库名可以推导出管理员，这不就存在局部依赖么。

老师讲的浅显易懂，学完本章节，又重新温故了一下三范式。