数据库的反范式化（Denormalization）设计

范式化设计目标的主要目的就是“减少不必要的更新”。但事事都具有两面性，在对数据库进行范式话设计的时候也不可避免的带来了一些副作用。一个完全范式化设计的数据库经常会面临“查询缓慢”这个问题。数据库越范式化，就需要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的这组数据吧。