数据库的最初雏形据说源自美国一个奶牛场的记账薄(U质的，由此可见Q数据库q不一定是存储在电脑里的数据^_^)Q里面记录的是该奶牛场的收支账目Q程序员在将其整理、录入到电脑中时从中受到启发。当按照规定好的数据l构所采集到的数据量大C定程度后Q出于程序执行效率的考虑Q程序员其中的索、更新维护等功能分离出来Q做成单独调用的模块Q这个模块后来就慢慢发展、演变成现在我们所接触到的数据?nobr>理pȝ(DBMS)——程序开发中的一个重要分支?/p>
下面q入正题Q首先按我个人所接触q的E序l数据库设计人员的功底分一下类Q?br />
Q、没有系l学习过数据l构的程序员。这cȝ序员的作品往往只是他们的即兴玩P他们往往习惯只设计有限的几个表，实现某类功能的数据全部塞在一个表中，各表之间几乎毫无兌。网上不的免费
我个人正处于W三cȝ末期Q所以下面所列出的一些设计技巧只适合W二cd部分W三cL据库设计人员。同Ӟ׃我很碰到有兴趣在这斚w深钻下去的同行，所以文中难免出现错误和遗漏Q在此先行声明，Ƣ迎大家指正Q不要藏U哦8)
一、树型关pȝ数据?br /> 不少E序员在q行数据库设计的时候都遇到q树型关pȝ数据Q例如常见的cd表，即一个大c，下面有若q个子类Q某些子cd有子c这L情况。当cd不确定，用户希望可以在Q意类别下d新的子类Q或者删除某个类别和其下的所有子c，而且预计以后其数量会逐步增长Q此时我们就会考虑用一个数据表来保存这些数据。按照教U书上的教导Q第二类E序员大概会设计出类DL数据表结构：
cd表_1(Type_table_1)
名称 cd U束条g 说明
type_id int 无重复 cd标识Q主?br />
type_name char(50) 不允ؓI?nbsp; cd名称Q不允许重复
type_father int 不允ؓI?nbsp; 该类别的父类别标识，如果是顶节点的话讑֮为某个唯一?/p>
q样的设计短精悍，完全满3NFQ而且可以满用户的所有要求。是不是q样p呢？{案是NOQWhyQ?/p>
我们来估计一下用户希望如何罗列出q个表的数据的。对用户而言Q他当然期望按他所讑֮的层ơ关pMơ罗列出所有的cdQ例如这P
ȝ?br />
cd1
cd1.1
cd1.1.1
cd1.2
cd2
cd2.1
cd3
cd3.1
cd3.2
……
看看Z实现q样的列表显C?树的先序遍历)Q要对上面的表进行多次索？注意Q尽类?.1.1可能是在cd3.2之后d的记录，{案仍然是Nơ。这L效率对于量的数据没什么媄响，但是日后cd扩充到数十条甚至上百条记录后Q单单列一ơ类型就要检索数十次该表Q整个程序的q行效率׃敢恭l了。或许第二类E序员会_那我再徏一个时数l或临时表，专门保存cd表的先序遍历l果Q这样只在第一ơ运行时索数十次Q再ơ罗列所有的cd关系时就直接读那个时数l或临时表就行了。其实，用不着再去分配一块新的内存来保存q些数据Q只要对数据表进行一定的扩充Q再Ҏ加类型的数量q行一下约束就行了Q要完成上面的列表只需一ơ检索就行了。下面是扩充后的数据表结构：
cd表_2(Type_table_2)
名称 cd U束条g 说明
type_id int 无重复 cd标识Q主?br />
type_name char(50) 不允ؓI?nbsp; cd名称Q不允许重复
type_father int 不允ؓI?nbsp; 该类别的父类别标识，如果是顶节点的话讑֮为某个唯一?br />
type_layer char(6) 限定3?初始gؓ000000 cd的先序遍历，主要为减检索数据库的次?/p>
按照q样的表l构Q我们来看看上面例子记录在表中的数据是怎样的：
type_id type_name type_father type_layer
1 ȝ?nbsp; 0 000000
2 cd1 1 010000
3 cd1.1 2 010100
4 cd1.2 2 010200
5 cd2 1 020000
6 cd2.1 5 020100
7 cd3 1 030000
8 cd3.1 7 030100
9 cd3.2 7 030200
10 cd1.1.1 3 010101
……
现在按type_layer的大来索一下：SELECT * FROM Type_table_2 ORDER BY type_layer
列出记录集如下：
type_id type_name type_father type_layer
1 ȝ?nbsp; 0 000000
2 cd1 1 010000
3 cd1.1 2 010100
10 cd1.1.1 3 010101
4 cd1.2 2 010200
5 cd2 1 020000
6 cd2.1 5 020100
7 cd3 1 030000
8 cd3.1 7 030100
9 cd3.2 7 030200
……
现在列出的记录顺序正好是先序遍历的结果。在控制昄cd的层ơ时Q只要对type_layer字段中的数D行判断，?位一l，如大?则向右移2个空根{当Ӟ我这个例子中讑֮的限制条件是最?层，每层最多可?9个子cdQ只要按用户的需求情况修改一下type_layer的长度和位数Q即可更攚w制层数和子类别数。其实，上面的设计不单单只在cd表中用到Q网上某些可按树型列表显C的论坛E序大多采用cM的设计?/p>
或许有h认ؓQType_table_2中的type_father字段是冗余数据，可以除去。如果这P在插入、删除某个类别的时候，得对type_layer 的内容进行比较繁琐的判定Q所以我q没有消去type_father字段Q这也正W合数据库设计中适当保留冗余数据的来降低E序复杂度的原则Q后面我会D一个故意增加数据冗余的案例?/p>
二、商品信息表的设?br />
假设你是一家百货公司电脑部的开发h员，某天老板要求你ؓ公司开发一套网?nobr>电子商务q_Q该百货公司有数千种商品出售Q不q目前仅打算先在|上销售数十种方便q输的商品，当然Q以后可能会陆箋在该电子商务q_上增加新的商品出售。现在开始进行该q_数据库的商品信息表的设计。每U出售的商品都会有相同的属性，如商品编P商品名称Q商品所属类别，相关信息Q供货厂商，内含件数Q库存，q货P销售hQ优惠h。你很快p计出4个表Q商品类型表(Wares_type)Q供货厂商表(Wares_provider)Q商品信息表(Wares_info)Q?/p>
商品cd?Wares_type)
名称 cd U束条g 说明
type_id int 无重复 cd标识Q主?br />
type_name char(50) 不允ؓI?nbsp; cd名称Q不允许重复
type_father int 不允ؓI?nbsp; 该类别的父类别标识，如果是顶节点的话讑֮为某个唯一?br />
type_layer char(6) 限定3?初始gؓ000000 cd的先序遍历，主要为减检索数据库的次?/p>
供货厂商?Wares_provider)
名称 cd U束条g 说明
provider_id int 无重复 供货商标识，主键
provider_name char(100) 不允ؓI?nbsp; 供货商名U?/p>
商品信息?Wares_info)
名称 cd U束条g 说明
wares_id int 无重复 商品标识Q主?br />
wares_name char(100) 不允ؓI?nbsp; 商品名称
wares_type int 不允ؓI 商品cd标识Q和Wares_type.type_id兌
wares_info char(200) 允许为空 相关信息
provider int 不允ؓI?nbsp; 供货厂商标识Q和Wares_provider.provider_id兌
setnum int 初始gؓ1 内含件数Q默认ؓ1
stock int 初始gؓ0 库存Q默认ؓ0
buy_price money 不允ؓI?nbsp; q货?br />
sell_price money 不允ؓI?nbsp; 销售h
discount money 不允ؓI?nbsp; 优惠?/p>
你拿着q?个表l老板查，老板希望能够再添加一个商品图片的字段Q不q只有一部分商品有图片。OKQ你在商品信息表(Wares_info)中增加了一个haspic的BOOL型字D，然后再徏了一个新表——商品图片表(Wares_pic)Q?/p>
商品囄?Wares_pic)
名称 cd U束条g 说明
pic_id int 无重复 商品囄标识Q主?br />
wares_id int 不允ؓI?nbsp; 所属商品标识，和Wares_info.wares_id兌
pic_address char(200) 不允ؓI 囄存放路径
E序开发完成后Q完全满板目前的要求，于是正式启用。一D|间后Q老板打算在这套^C推出新的商品销售，其中Q某cd品全部都需d“长度”的属性。第一轮折腾来?#8230;…当然Q你按照d商品囄表的老方法，在商品信息表(Wares_info)中增加了一个haslength的BOOL型字D，又徏了一个新表——商品长度表(Wares_length)Q?/p>
商品长度?Wares_length)
名称 cd U束条g 说明
length_id int 无重复 商品囄标识Q主?br />
wares_id int 不允ؓI?nbsp; 所属商品标识，和Wares_info.wares_id兌
length char(20) 不允ؓI 商品长度说明
刚刚改完没多久，老板又打上一Ҏ的商品，q次某类商品全部需要添?#8220;宽度”的属性。你咬了咬牙Q又照方抓药Q添加了商品宽度?Wares_width)。又q了一D|_老板C的商品中有一些需要添?#8220;高度”的属性，你是不是开始觉得你所设计的数据库按照q种方式增长下去Q很快就能变成一个迷宫呢Q那么，有没有什么办法遏制这U不可预见性，但却cM重复的数据库膨胀呢？我在阅读《敏捯Y件开发：原则、模式与实践》中发现作者Dq类似的例子Q?.3 “Copy”E序。其中，我非常赞同敏捯Y件开发这个观点：在最初几乎不q行预先设计Q但是一旦需求发生变化，此时作ؓ一名追求卓的E序员，应该从头审查整个架构设计Q在此次修改中设计出能够满日后cM修改的系l架构。下面是我在需要添?#8220;长度”的属性时所提供的修Ҏ案：
L商品信息?Wares_info)中的haspic字段Q添加商品额外属性表(Wares_ex_property)和商品额外信息表(Wares_ex_info)2个表来完成添加新属性的功能?/p>
商品额外属性表(Wares_ex_property)
名称 cd U束条g 说明
ex_pid int 无重复 商品额外属性标识，主键
p_name char(20) 不允ؓI?nbsp; 额外属性名U?/p>
商品额外信息?Wares_ex_info)
名称 cd U束条g 说明
ex_iid int 无重复 商品额外信息标识Q主?br />
wares_id int 不允ؓI?nbsp; 所属商品标识，和Wares_info.wares_id兌
property_id int 不允ؓI 商品额外属性标识，和Wares_ex_property.ex_pid兌
property_value char(200) 不允ؓI?nbsp; 商品额外属性?/p>
在商品额外属性表(Wares_ex_property)中添?条记录：
ex_pid p_name
1 商品囄
2 商品长度
再在整个电子商务q_的后台管理功能中q加一商品额外属性管理的功能Q以后添加新的商品时出现新的属性，只需利用该功能往商品额外属性表(Wares_ex_property)中添加一条记录即可。不要害怕变化，被第一颗子弹击中ƈ不是坏事Q坏的是被相同轨道飞来的W二颗、第三颗子弹M。第一颗子Ҏ得越早，所受的伤越重，之后的抵抗力也越?)
三、多用户及其权限
开?nobr>数据?/strong>理cȝ
1.那些大、中型后台数据库pȝ软g所提供的多用户及其权限讄都是针对数据库的共有属性，q不一定能完全满某些特例的需求；
2.不要q多的依赖后台数据库pȝ软g的某些特D功能，多种大、中型后台数据库pȝ软g之间q不完全兼容。否则一旦日后需要{换数据库q_或后台数据库pȝ软g版本升Q之前的架构设计很可能无法重用?
下面看看如何自行设计一套比较灵zȝ多用L理模块，卌数据库管理Y件的pȝ理员可以自行添加新用户Q修改已有用L权限Q删除已有用戗首先，分析用户需求，列出该数据库理软g所有需要实现的功能Q然后，Ҏ一定的联系对这些功能进行分c，x某类用户需使用的功能归Zc；最后开始徏表：
功能?Function_table)
名称 cd U束条g 说明
f_id int 无重复 功能
f_desc char(50) 允许为空 功能描述
用户l表(User_group)
名称 cd U束条g 说明
group_id int 无重?nbsp; 用户l标识，主键
group_name char(20) 不允ؓI?nbsp; 用户l名U?br />
group_power char(100) 不允ؓI?nbsp; 用户l权限表Q内容ؓ功能表f_id的集?/p>
用户?User_table)
名称 cd U束条g 说明
user_id int 无重?nbsp; 用户标识Q主?br />
user_name char(20) 无重?nbsp; 用户?br />
user_pwd char(20) 不允ؓI?nbsp; 用户密码
user_type int 不允ؓI?nbsp; 所属用L标识Q和User_group.group_id兌
采用q种用户l的架构设计Q当需要添加新用户Ӟ只需指定新用h属的用户l；当以后系l需要添加新功能或对旧有功能权限q行修改Ӟ只用操作功能表和用户l表的记录，原有用户的功能即可相应随之变化。当Ӟq种架构设计把数据库理软g的功能判定移C前台Q得前台开发相对复杂一些。但是，当用h较大(10Z?Q或日后软g升的概率较大时Q这个代h值得的?/p>
四、简z的扚wm:n设计
到m:n的关p，一般都是徏?个表Qm一个，n一个，m:n一个。但是，m:n有时会遇到批量处理的情况Q例如到图书馆借书Q一般都是允许用户同时借阅n本书Q如果要求按Ҏ询借阅记录Q即列出某个用户某次借阅的所有书c，该如何设计呢Q让我们建好必须?个表先：
书籍?Book_table)
名称 cd U束条g 说明
book_id int 无重?nbsp; 书籍标识Q主?br />
book_no char(20) 无重?nbsp; 书籍~号
book_name char(100) 不允ؓI?nbsp; 书籍名称
……
借阅用户?Renter_table)
名称 cd U束条g 说明
renter_id int 无重?nbsp; 用户标识Q主?br />
renter_name char(20) 不允ؓI?nbsp; 用户姓名
……
借阅记录?Rent_log)
名称 cd U束条g 说明
rent_id int 无重?nbsp; 借阅记录标识Q主?br />
r_id int 不允ؓI?nbsp; 用户标识Q和Renter_table.renter_id兌
b_id int 不允ؓI?nbsp; 书籍标识Q和Book_table.book_id兌
rent_date datetime 不允ؓI?nbsp; 借阅旉
……
Z实现按批查询借阅记录Q我们可以再Z个表来保存批量借阅的信息，例如Q?/p>
扚w借阅?Batch_rent)
名称 cd U束条g 说明
batch_id int 无重?nbsp; 扚w借阅标识Q主?br />
batch_no int 不允ؓI?nbsp; 扚w借阅~号Q同一批借阅的batch_no相同
rent_id int 不允ؓI?nbsp; 借阅记录标识Q和Rent_log.rent_id兌
batch_date datetime 不允ؓI?nbsp; 扚w借阅旉
q样的设计好吗？我们来看看ؓ了列出某个用hơ借阅的所有书c，需要如何查询？首先索批量借阅?Batch_rent)Q把W合条g的的所有记录的rent_id字段的数据保存v来，再用q些数据作ؓ查询条g带入到借阅记录?Rent_log)中去查询。那么，有没有什么办法改q呢Q下面给ZU简z的扚w设计ҎQ不需d新表Q只需修改一下借阅记录?Rent_log)卛_。修改后的记录表(Rent_log)如下Q?/p>
借阅记录?Rent_log)
名称 cd U束条g 说明
rent_id int 无重?nbsp; 借阅记录标识Q主?br />
r_id int 不允ؓI?nbsp; 用户标识Q和Renter_table.renter_id兌
b_id int 不允ؓI?nbsp; 书籍标识Q和Book_table.book_id兌
batch_no int 不允ؓI?nbsp; 扚w借阅~号Q同一批借阅的batch_no相同
rent_date datetime 不允ؓI?nbsp; 借阅旉
……
其中Q同一ơ借阅的batch_no和该批第一条入库的rent_id相同。D例：假设当前最大rent_id?4Q接着某用户一ơ借阅?本书Q则扚w插入?条借阅记录的batch_no都是65。之后另外一个用L了一套碟Q再插入出租记录的rent_id?8。采用这U设计，查询扚w借阅的信息时Q只需使用一条标准T_SQL的嵌套查询即可。当Ӟq种设计不符?NFQ但是和上面标准?NF设计比v来，哪一U更好呢Q答案就不用我说了吧?/p>
五、冗余数据的取舍
上篇?#8220;树型关系的数据表”中保留了一个冗余字D，q里的例子更q一步——添加了一个冗余表。先看看例子Q我原先所在的公司Z解决员工的工作餐Q和附近的一家小馆联系Q每天吃饭记账，费用按h数^摊，月底由公司现金结，每个人每个月的工作餐费从工资中扣除。当Ӟ每天吃饭的h员和人数都不是固定的Q而且Q由于每工作餐的所点的菜色不同Q每的p也不相同。例如，星期一中餐5?0元，晚餐2?0Q星期二中餐6?6元，晚餐3?8元。ؓ了方便计每个h每个月的工作费Q我写了一个简陋的餐记̎理E序Q数据库里有3个表Q?/p>
员工?Clerk_table)
名称 cd U束条g 说明
clerk_id int 无重?nbsp; 员工标识Q主?br />
clerk_name char(10) 不允ؓI?nbsp; 员工姓名
每餐总表(Eatdata1)
名称 cd U束条g 说明
totle_id int 无重?nbsp; 每餐总表标识Q主?br />
persons char(100) 不允ؓI?nbsp; 餐员工的员工标识集?br />
eat_date datetime 不允ؓI?nbsp; 餐日期
eat_type char(1) 不允ؓI?nbsp; 餐cdQ用来区分中、晚?br />
totle_price money 不允ؓI?nbsp; 每餐总花?br />
persons_num int 不允ؓI?nbsp; 餐人数
餐
名称 cd U束条g 说明
id int 无重?nbsp; 餐计费l表标识Q主?br />
t_id int 不允ؓI?nbsp; 每餐总表标识Q和Eatdata1.totle_id兌
c_id int 不允ؓI?nbsp; 员工标识标识Q和Clerk_table.clerk_id兌
price money 不允ؓI?nbsp; 每h每餐p
其中Q就计费细?Eatdata2)的记录就是把每餐总表(Eatdata1)的一条记录按餐员工qx拆开Q是个不折不扣的冗余表。当Ӟ也可以把每餐总表(Eatdata1)的部分字D合q到餐计费l表(Eatdata2)中，q样每餐总表(Eatdata1)成了冗余表Q不q这h设计出来的就计费细表重复数据更多，相比来说q是上面的方案好些。但是，是餐计费l表(Eatdata2)q个冗余表，在做每月每h费l计的时候，大大化了~程的复杂度Q只用类D么一条查询语句即可统计出每h每月的寄次数和费dQ?/p>
SELECT clerk_name AS personname,COUNT(c_id) as eattimes,SUM(price) AS ptprice FROM Eatdata2 JOIN Clerk_tabsle ON (c_id=clerk_id) JOIN eatdata1 ON (totleid=tid) WHERE eat_date>=CONVERT(datetime,'"&the_date&"') AND eat_date<DATEADD(month,1,CONVERT(datetime,'"&the_date&"')) GROUP BY c_id
惌一下，如果不用q个冗余表，每次l计每h每月的餐Ҏd时会多麻烦，E序效率也够呛。那么，到底什么时候可以增加一定的冗余数据呢？我认为有2个原则：
Q、用L整体需求。当用户更多的关注于Q对数据库的规范记录按一定的法q行处理后，再列出的数据。如果该法可以直接利用后台数据库系l的内嵌函数来完成，此时可以适当的增加冗余字D，甚至冗余表来保存q些l过法处理后的数据。要知道Q对于大扚w数据的查询，修改或删除，后台数据库系l的效率q远高于我们自己~写的代码?br />
Q、简化开发的复杂度。现代Y件开发，实现同样的功能，Ҏ有很多。尽不必要求程序员_N绝大部分的开发工具和q_Q但是还是需要了解哪U方法搭配哪U开发工LE序更简z，效率更高一些。冗余数据的本质是用空间换旉Q尤其是目前g的发展远q高于YӞ所以适当的冗余是可以接受的。不q我q是在最后再一下：不要q多的依赖^台和开发工LҎ来化开发，q个度要是没把握好的话，后期l护升会栽大跟头的?/p>