日记 [2008年02月02日]

fengyushb

数据库设计三大范式如雷贯耳，但作为非科班出身的我直到两个月前竟然都不知道三大范式究竟是什么。那么三大范式是什么？
引用
第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。
第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。
两个月前当我购买了一本《MySQL权威指南》，翻到三大范式的定义的时候，我内心巨震，三大范式简单总结一句就是消除冗余，单纯依赖关系。不允许数据库表出现冗余字段，不允许表之间多重依赖，因此符合三大范式设计的数据库模型其实和你按照面向对象思想去建模得到的数据库模型是一样的。
所以不论你是从数据库为中心建模，还是你以领域模型为中心建模，你应该最终得到一个一致的数据库模型。之所以导致数据库建模和OO建模的不一致，是因此传统的数据库建模从来都是违背三大范式的。而我们在过去经常说的一句话就是：为了数据库查询性能，我们需要多加一些冗余字段，不一定非要遵循三大范式......
所以不要再说什么数据库设计和面向对象设计导致的数据模型冲突的话，不是他们冲突，是你违背了三大范式，自己制造出来的冲突

JavaEye网站的数据库设计是面向对象为中心的设计，但是拿三大范式来衡量，大部分设计都是吻合的，而我们的数据库缓存命中率在90%左右。缓存服务器的流量是数据库服务器流量的2.5倍之多。事实上我们有很多地方的查询尽量避免join，宁可让他n+1，这样速度反而更快，缓存命中率更高。
例如我们现在把帖子的内容字段拆分出来，单独放在一个post_texts表里面。这样posts表实际上只有35MB，而post_texts表有1GB。每次显示一个post，都会用主键去load post_text，命中缓冲。不需要查数据库，不需要去碰那个1GB的大表。
要充分发挥ORM的缓存优势，就必须把表设计的尽量细颗粒度，消除冗余和多重依赖，最终可能是相当多的小表，表之间通过主外键关联，但是关联关系都是单一的。那么这种追求面向对象的数据库模型是非常符合三大范式的。

我只想举一个例子，Google在使用Hibernate，并且Google开发了一个叫做Hibernate Shards的分布式工具，将Hibernate运用在大规模分布式数据库环境当中，Hibernate Shards现在也是开源的，在Hibnerate网站上面就可以找到文档


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/41980/showart_475210.html