数据的规范化与非规范化

16-10-01 banq
              

本文预言将会出现一种非规范化数据库引擎,它的出现类似当初关系数据库或NoSQL出现一样,会导致革命性的前进。

对于一个需求,我们一般有两个实现方向:normalized规范化和 denormalized 非规范化。

Normalized规范化就是我们建立一个应用总是需要设计一个核心数据类型图表Schema和字段(数据表结构),这是使用数据库之前绝对需要的一步。

设计规范的表结构是一个巨大的产品定义工作,好的程序员会花费很多精力在思考应用的数据库表结构。

如果放弃完全的Normalized规范化表结构,实现Denormalized 非规范化,会得到很好的查询效率和性能,添加一些逻辑冗余非规范化字段到表结构中。

比如产品名称一般是在产品表中,订单表中只有产品ID,不会有产品名称,但是如果结合订单日期查询相关产品名称,需要结合产品表和订单表:

SELECT product_name, order_date
FROM orders INNER JOIN products USING(product_id)
WHERE product_name like 'A%'
ORDER by order_date DESC 
<p>

这是基于规范化表结构的查询,无疑效率性能低,非结构化表结构设计是在订单表中加入产品名称这个字段,这样就不会使用到产品表,只有单表查询了:

SELECT product_name, order_date
FROM orders
WHERE product_name like 'A%'
ORDER by order_date DESC 
<p>

无疑非规范化性能提高了读取效率。

但是使用非规范化表结构设计会使得我们的业务逻辑代码没有凝聚性,到处散落。

规范化表结构方法,尽管有其性能缺陷,至少能让我们使用一个函数将查询封装起来,这个函数可以被任何代码引用,这是灵活的。

非规范化表结构方法虽然有读取性能优势,但是在需求改变时,改变表结构字段定义时,会打破我们精心推理和精心优化的代码。

非规范化方法还有一个好处,不需要预先严格定义表结构,不需要煞费苦心寻找领域聚合和规律,特别是在互联网创新企业,没有人告诉你产品未来应该是什么样?产品经理也无法预先定义,唯一不变的是变化,使用非规范化方法在没有严格表结构设计下搜集数据,让系统跑起来运行起来,以后根据当时设计思路再进行各种字段的聚合汇总,重新计算写入规范化表结构中,但是这种转换是目前最大难题,没有统一产品,Apache Kafka只是一个具体开源产品。

业界正在协调这两种矛盾,比如Oracle使用物化视图 materialized views 以及Event Sourcing。这两个都有其缺陷,ES的缺陷是缺乏一种非规范化数据库引擎将事件对象流转为规范化表结构。

现在业界迁移到非规范化表结构是一种范式趋势,预期在以后几年会有强大的非规范化引擎发明出来。这将是下一次企业技术的前沿革命性领域。

以上只是看到下面文章进行意译和加入一些个人不成熟的想法,原文参考:

Data denormalization is broken

              

2