数据库的反范式化（Denormalization）设计
在转载：数据库范式1NF 2NF 3NF BCNF实例分解这篇博文中，介绍了数据库范式设计方面的内容。
范式化设计目标的主要目的就是“减少不必要的更新”。但事事都具有两面性，在对数据库进行范式话设计的时候也不可避免的带来了一些副作用。一个完全范式化设计的数据库经常会面临“查询缓慢”这个问题。数据库越范式化，就需要Join越多的表。例如，把用户地址用独立的一张表来存储，在需要显示用户地址的时候就需要去join用户地址表。
数据库的范式设计其中的一些优点可能并不这么值得称道:
范式化节省了存储空间，但存储空间却很便宜
范式化简化了更新，但读更普遍
反范式化设计
对不可改变数据的反模式设计。也就是说对不可改变的数据无需模式化设计。例如，用户信息中要记录该用户的国籍，由于国家信息（国家代码、简称都是不可改变的数据或者说改变的机率很小），所以无需在用户信息表中新增列来关联国家信息表，可以直接将相关的国家信息列作为用户信息表中的列。
将多张表合并成一张。下面举一个这样的例子，范式化的数据库设计如下。
| user table用户基本信息表 | ||||||||
|---|---|---|---|---|---|---|---|---|
| user_id | first_name | last_name | sex | hometown | relationship_status | |||
| 12345 | John | Doe | Male | Atlanta, GA | married | |||
| user_phone_numbers table用户电话信息表 | ||
|---|---|---|
| user_id (foreign_key) | phone_number | phone_type |
| 12345 | 425-555-1203 | Home |
| 12345 | 425-555-6161 | Work |
| 12345 | 206-555-0932 | Cell |
| user_screen_names table用户IM信息表 | ||
|---|---|---|
| user_id (foreign_key) | screen_name | im_service |
| 12345 | geeknproud@example.com | AIM |
| 12345 | voip4life@example.org | Skype |
对这样的表设计进行反模式就可以将user_phone_numbers table，user_screen_names table都并入user table中。
| user_table用户IM信息表 | |
|---|---|
| 列名 | 说明 |
| user_id | |
| first_name | |
| last_name | |
| sex | |
| hometown | |
| relationship_status | |
| phone_type_home | |
| phone_type_work | |
| phone_type_cell | |
| im_service_aim | |
| … | |
在提升数据库性能的时候我们可以考虑索引、物化视图、缓存等技术，但反范式设计的确是很重要的一种手段。看一下Flickr的这组数据吧。
total stored unique data : 935 GB
total stored duplicated data : ~3TB
参考资料
Why too much Database Normalization can be a Bad Thing
要过年了。上网人多就卡，悲哀 。