数据库设计综合规范和值得注意的问题.docx

假如把企业数据比做生命所必需血液，那么数据库设计就是应用中最关键一部分。相关数据
库设计材料汗牛充栋，大学学位课程里也有专门讲述。不过，就如我们反复强调那样，再好
老师也比不过经验教育。所以我们最近找了些对数据库设计颇有造诣专业人士给大家传授部分设
计数据库技巧和经验。我们编辑从收到130 个反馈中精选了其中60 个最好技巧，并把这些
技巧编写成了本文，为了方便索引其内容划分为5 个部分：
第1 部分— 设计数据库之前
这一部分罗列了12 个基础技巧，包含命名规范和明确业务需求等。
第2 部分— 设计数据库表
总共24 个指南性技巧，涵盖表内字段设计和应该避免常见问题等。
第3 部分— 选择键
怎么选择键呢？这里有10 个技巧专门包含系统生成主键正确使用方法，还有何时和怎样索引字段
以取得最好性能等。
第 4 部分 — 确保数据完整性
讨论怎样保持数据库清楚和健壮，怎样把有害数据降低到最小程度。
第5 部分— 多种小技巧
不包含在以上4 个部分中其它技巧，五花八门，有 了它们期望你数据库开发工作会更轻松部分。

第1 部分— 设计数据库之前
1. 考察现有环境
在设计一个新数据库时，你不仅应该仔细研究业务需求而且还要考察现有系统。大多数数据库
项目全部不是从头开始建立；通常，机构内总会存在用来满足特定需求现有系统（可能没有实
现自动计算）。显然，现有系统并不完美，不然你就无须再建立新系统了。不过对旧系统研究
能够让你发觉部分可能会忽略细微问题。通常来说，考察现有系统对你绝对有好处。
— Lamont Adams
我曾经接手过一个为地域运输企业开发数据库项目，活不难，用是Access 数据库。我设置
了部分项目设计参数，而且同用户一道对这些参数进行了评定，事先还查看了开发环境下所采取
工作模式，等到最终布署应用时候，只见终端上出了多个提醒符然后立马在我面前翘辫子
了！抓耳挠腮折腾了好多个小时，我才意识到，原来这家企业网络上跑着两个数据库应用，
而对网络访问需要明确和严格用户帐号及其访问权限。明白了这一点，问题迎刃而解：只需
采取用户系统即可。这个项目给我教训就是：记住，假如你在诸如Access 或Interbase 这
类公共环境下开发应用程序，一定要从表面下手深入系统内部搞清楚你面临环境到底是怎么回
事。
— kg
2. 定义标准对象命名规范
一定要定义数据库对象命名规范 。对数据库表来说，从项目一开始就要确定表名是采取复数还
是单数形式。另外还要给表别名定义简单规则（比方说，假如表名是一个单词，别名就取单词
前4 个字母；假如表名是两个单词，就各取两个单词前两个字母组成4 个字母长别名；如
果表名字由3 个单词组成，你不妨从头两个单词中各取一个然后从最终一个单词中再取出两个
字母，结果还是组成4 字母长别名，其它依次类推）对工作用表来说，表名能够加上前缀
WORK_ 后面附上采取该表应用程序名字。表内列要针对键采取一整套设计规则。比如，
假如键是数字类型，你能够用_NO 作为后缀；假如是字符类型则能够采取 _CODE 后缀。对列名
应该采取标准前缀和后缀。再如，假如你表里有好多“money”字段，你不妨给每个列增加
一个_AMT 后缀。还有，日期列最好以DATE_作为名字打头。
— richard
检验表名、报表名和查询名之间命名规范。你可能会很快就被这些不一样数据库要素名称搞
糊涂了。假如你坚持统一地命名这些数据库不一样组成部分，最少你应该在这些对象名字开头
用table、query 或report 等前缀加以区分。
— rrydenm
假如采取了Microsoft Access，你能够用 qry、rpt、 tbl 和mod 等符号来标识对象（比如
tbl_Employees）。我在和SQL Server（或Oracle）打交道时候还用过tbl 来索引表，但我
用sp_company （现在用sp_feft_）标识存放过程，因为在有时候假如我发觉了愈加好处理办
法往往会保留好多个拷贝。我在实现 SQL Server 时用udf_ （或类似标识）标识我编
写函数。
— Timothy J. Bruce

3. 预先计划
上个世纪80 年代初，我还在使用资产帐目系统和System 38 平台，那时我负责设计全部日期
字段，这么在不费什么力气情况下未来就能够轻松处理 年问题了。很多人给我说就别去
处理这一问题了，因为要处理起来太麻烦了（这在世人皆知Y2K 问题之前很久了）。我回击说
只要预先计划以后就不会碰到大麻烦。结果我只用了两周时间就把程序全部改完了。因为预先
计划好，以后Y2K 问题对该系统危害降到了最低程度（最近听说该程序甚至到了1995 年全部
还运行在AS/400 系统上，唯一出现小问题是从代码中删除注释费了点工夫）。
— generalist
4. 获取数据模式资源手册
正在寻求示例模式人能够阅读《 数据模式资源手册 》一书，该书由Len Silverston、W. H.
Inmon 和Kent Graziano 编写，是一本值得拥有最好数据建模图书。该书包含章节涵盖多个
数据领域，比如人员、机构和工作效能等。
— minstrelmike
5. 畅想未来，但不可忘了过去教训
我发觉问询用户怎样看待未来需求改变很有用。这么做能够达成两个目标：首先，你能够清楚
地了解应用设计在哪个地方应该更具灵活性和怎样避免性能瓶颈；其次，你知道发生事先没有
确定需求变更时用户将和你一样感到吃惊。
— chrisdk
一定要记住过去经验教训！我们开发人员还应该经过分享自己体会和经验相互帮助。即使用
户认为她们再也不需要什么支持了，我们也应该对她们进行这方面教育，我们全部曾经面临过这
样时刻“当初要是这么做了该多好⋯⋯”。
— dhattrem
6. 在物理实践之前进行逻辑设计
在深入物理设计之前要优异行逻辑设计。伴随大量 CASE 工具不停涌现出来，你设计也能够
达成相当高逻辑水准，你通常能够从整体上愈加好地了解数据库设计所需要方方面面。
— chardove
7. 了解你业务
在你百分百地确定系统从用户角度满足其需求之前不要在你ER（实体关系）模式中加入哪怕
一个数据表（怎么，你还没有模式？那请你参看技巧9）。了解你企业业务能够在以后开发
阶段节省大量时间。一旦你明确了业务需求，你就能够自己做出很多决议 了。
— rangel
一旦你认为你已经明确 了业务内容，你最好同用户进行一次系统交流。采取用户术语而且向
她们解释你所想到和你所听到。同时还应该用可能、将会和必需等词汇表示出系统关系基
数。这么你就能够让你用户纠正你自己了解然后做好下一步ER 设计。
— teburlew

8. 创建数据字典和ER 图表
一定要花点时间创建ER 图表和数据字典。其中最少应该包含每个字段数据类型和在每个表内
主外键。创建ER 图表和数据字典确实有点费时但对其它开发人员要了解整个设计却是完全必
要。越早创建越能有利于避免以后面临可能混乱，从而能够让任何了解数据库人全部明确如
何从数据库中取得数据。
— bgumbert
有一份诸如ER 图表等最新文档其关键性怎样强调全部不过分，这对表明表之间关系很有用，而数
据字典则说明了每个字段用途和任何可能存在别名。对SQL 表示式文档化来说这是完
全必需。
— vanduin.chris.cj
9. 创建模式
一张图表胜过千言万语：开发人员不仅要阅读和实现它，而且还要用它来帮助自己和用户对话。
模式有利于提升协作效能，这么在先期数据库设计中几乎不可能出现大问题。模式无须弄
很复杂；甚至能够简单到手写在一张纸上就能够了。只是要确保其上逻辑关系以后能产生效
益。
— Dana Daigle
10. 从输入输出下手
在定义数据库表和字段需求（输入）时，首先应检验现有或已经设计出报表、查询和视图
（输出）以决定为了支持这些输出哪些是必需表和字段。举个简单例子：假如用户需要一个
报表根据邮政编码排序、分段和求和，你要确保其中包含了单独邮政编码字段而不要把邮政编
码糅进地址字段里。
— peter.marshall
11. 报表技巧
要了解用户通常是怎样汇报数据：批处理还是在线提交报表？时间间隔是天天、每七天、每个月、
每个季度还是每十二个月？假如需要话还能够考虑创建总结表。系统生成主键在报表中极难管理。
用户在含有系统生成主键表内用副键进行检索往往会返回很多反复数据。这么检索性能比较
低而且轻易引发混乱。
— kol
12. 了解用户需求
看起来这应该是显而易见事，但需求就是来自用户（这里要从内部和外部用户角度考虑）。
不要依靠用户写下来需求，真正需求在用户脑袋里。你要让用户解释其需求，而且伴随开
发继续，还要常常问询用户确保其需求仍然在开发目标之中。一个不变真理是：“只有我
看见了我才知道我想要是什么”肯定会造成大量返工，因为数据库没有达成用户历来没有写
下来需求标准。而更糟是你对她们需求解释只属于你自己，而且可能是完全错误。
— kgilson

第2 部分— 设计表和字段
1. 检验多种改变
我在设计数据库时候会考虑到哪些数据字段未来可能会发生变更。比方说，姓氏就是如此（注
意是西方人姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存放用户信息时，我倾向于
在单独一个数据表里存放姓氏字段，而且还附加起始日和终止日等字段，这么就能够跟踪这一
数据条目标改变。
— Shropshire Lad
2. 采取有意义字段名
有一回我参与开发过一个项目，其中有从其它程序员那里继承程序，那个程序员喜爱用屏幕上
显示数据指示用语命名字段，这也不赖，但不幸是，她还喜爱用部分奇怪命名法，其命名采
用了匈牙利命名和控制序号组合形式，比如cbo1、 txt2、txt2_b 等等。
除非你在使用只面向你缩写字段名系统，不然请尽可能地把字段描述清楚些。当然，也别
做过头了，比如Customer_Shipping_Address_Street_Line_1 I 即使很富有说明性，但没人愿意
键入这么长名字，具体尺度就在你把握中。
— Lamont Adams
3. 采取前缀命名
假如多个表里有好多同一类型字段（比如FirstName），你不妨用特定表前缀（比如
CusLastName）来帮助你标识字段。
— notoriousDOG
时效性数据应包含“最近更新日期/时间”字段。时间标识对查找数据问题原因、按日期重新处
理/重载数据和清除旧数据尤其有用。
— kol
5. 标准化和数据驱动
数据标准化不仅方便了自己而且也方便了其它人。比方说，假如你用户界面要访问外部数据
源（文件、XML 文档、其它数据库等），你不妨把对应连接和路径信息存放在用户界面支持表
里。还有，假如用户界面实施工作流之类任务（发送邮件、打印信笺、修改统计状态等），那
么产生工作流数据也能够存放在数据库里。预先安排总需要付出努力，但假如这些过程采取数
据驱动而非硬编码方法，那么策略变更和维护全部会方便得多。实际上，假如过程是数据驱动
，你就能够把相当大责任推给用户，由用户来维护自己工作流过程。
— tduvall
6. 标准化不能过头
对那些不熟悉标准化一词（normalization ）人而言，标准化能够确保表内字段全部是最基础
要素，而这一方法有利于消除数据库中数据冗余。标准化有好多个形式，但Third Normal
Form（3NF）通常被认为在性能、扩展性和数据完整性方面达成了最好平衡。简单来说，3NF 规
定：

· 表内每一个值全部只能被表示一次。
· 表内每一行全部应该被唯一标识（有唯一键）。
· 表内不应该存放依靠于其它键非键信息。
遵守3NF 标准数据库含有以下特点：有一组表专门存放经过键连接起来关联数据。比方说，
某个存放用户及其相关定单3NF 数据库就可能有两个表：Customer 和Order。Order 表不包
含定单关联用户任何信息，但表内会存放一个键值，该键指向Customer 表里包含该用户信息
那一行。
更高层次标准化也有，但更标准是否就一定愈加好呢？答案是不一定。实际上，对一些项目来
说，甚至就连3NF 全部可能给数据库引入太高复杂性。
— Lamont Adams
为了效率缘故，对表不进行标准化有时也是必需，这么例子很多。曾经有个开发财务分析
软件活就是用非标准化表把查询时间从平均40 秒降低到了两秒左右。即使我不得不这么做，
但我绝不把数据表非标准化看成当然设计理念。而具体操作不过是一个派生。所以假如表
出了问题重新产生非标准化表是完全可能。
— epepke
7. Microsoft Access 报表技巧
假如你正在使用Microsoft Access，你能够用对用户友好字段名来替换编号名称：比如用
Customer Name 替换txtCNaM。这么，当你用向导程序创建表单和报表时，其名字会让那些不
是程序员人更轻易阅读。
— jwoodruf
8. 不活跃或不采取指示符
增加一个字段表示所在统计是否在业务中不再活跃挺有用。不管是用户、职员还是其它什么
人，这么做全部能有利于再运行查询时候过滤活跃或不活跃状态。同时还消除了新用户在采取
数据时所面临部分问题，比如，一些统计可能不再为她们所用，再删除时候能够起到一定
防范作用。
— theoden
9. 使用角色实体定义属于某类别列
在需要对属于特定类别或含有特定角色事物做定义时，能够用角色实体来创建特定时间关
联关系，从而能够实现自我文档化。
这里含义不是让PERSON 实体带有Title 字段，而是说，为何不用PERSON 实体和
PERSON_TYPE 实体来描述人员呢？然后，比方说，当 John Smith, Engineer 提升为John
Smith, Director 乃至最终爬到John Smith, CIO 高位，而全部你要做不过是改变两个表
PERSON 和PERSON_TYPE 之间关系键值，同时增加一个日期/时间字段来知道改变是何时
发生。这么，你PERSON_TYPE 表就包含了全部PERSON 可能类型，比如Associate、
Engineer、Director、CIO 或CEO 等。
还有个替换措施就是改变PERSON 统计来反应新头衔改变，不过这么一来在时间上无法跟踪
个人所处位置具体时间。

— teburlew
10. 采取常见实体命名机构数据
组织数据最简单措施就是采取常见名字，比如：PERSON、ORGANIZATION、ADDRESS 和
PHONE 等等。当你把这些常见通常名字组合起来或创建特定对应副实体时，你就得到了
自己用特殊版本。开始时候采取通常术语关键原因在于全部具体用户全部能对抽象事物具
体化。
有了这些抽象表示，你就能够在第2 级标识中采取自己特殊名称，比如，PERSON 可能是
Employee、Spouse、Patient、Client、Customer、Vendor 或Teacher 等。一样，
ORGANIZATION 也可能是MyCompany、MyDepartment、Competitor、Hospital、
Warehouse、Government 等。最终ADDRESS 能够具体为Site、Location、Home、Work、
Client、Vendor、Corporate 和FieldOffice 等。
采取通常抽象术语来标识“事物”类别能够让你在关联数据以满足业务要求方面取得巨大灵
活性，同时这么做还能够显著降低数据存放所需冗余量。
— teburlew
11. 用户来自世界各地
在设计用到网络或含有其它国际特征数据库时，一定要记住大多数国家全部有不一样字段格
式，比如邮政编码等，有些国家，比如新西兰就没有邮政编码一说。
— billh
12. 数据反复需要采取分立数据表
假如你发觉自己在反复输入数据，请创建新表和新关系。
— Alan Rash
13. 每个表中全部应该添加3 个有用字段
· dRecordCreationDate，在VB 下默认是Now()，而在SQL Server 下默认为GETDATE()
· sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER
· nRecordVersion，统计版本标识；有利于正确说明统计中出现null 数据或丢失数据原
因
— Peter Ritchie
14. 对地址和电话采取多个字段
描述街道地址就短短一行统计是不够。Address_Line1、Address_Line2 和Address_Line3 可
以提供更大灵活性。还有，电话号码和邮件地址最好拥有自己数据表，其间含有本身类型
和标识类别。
— dwnerd
过分标准化可要小心，这么做可能会造成性能上出现问题。即使地址和电话表分离通常能够达成
最好状态，不过假如需要常常访问这类信息，或许在其父表中存放“首选”信息（比如
Customer 等）更为妥当些。非标准化和加速访问之间妥协是有一定意义。
— dhattrem

15. 使用多个名称字段
我认为很吃惊，很多人在数据库里就给 name 留一个字段。我认为只有刚入门开发人员才会这
么做，但实际上网上这种做法很普遍。我提议应该把姓氏和名字看成两个字段来处理，然后在
查询时候再把她们组合起来。
— klempan
Klempan 不是唯一一个注意到使用单个name 字段人，要把这种情况变得对用户更为友好有好
些方法。我最常见是在同一表中创建一个计算列，经过它能够自动地连接标准化后字段，这
样数据变动时候它也跟着变。不过，这么做在采取建模软件时得很灵巧才行。总而言之，采取连接
字段方法能够有效隔离用户应用和开发人员界面。
— damon
16. 提防大小写混用对象名和特殊字符
过去最令我恼火事情之一就是数据库里有大小写混用对象名，比如CustomerData。这一问
题从Access 到Oracle 数据库全部存在。我不喜爱采取这种大小写混用对象命名方法，结果还不
得不手工修更名字。想想看，这种数据库/应用程序能混到采取更强大数据库那一天吗？采取全
部大写而且包含下划符名字含有愈加好可读性（CUSTOMER_DATA），绝对不要在对象名
字符之间留空格。
— bfren
17. 小心保留词
要确保你字段名没有和保留词、数据库系统或常见访问方法冲突，比如，最近我编写一个
ODBC 连接程序里有个表，其中就用了DESC 作为说明字段名。后果可想而知！DESC 是
DESCENDING 缩写后保留词。表里一个SELECT *语句倒是能用，但我得到却是一大堆
毫无用处信息。
— Daniel Jordan
18. 保持字段名和类型一致性
在命名字段并为其指定数据类型时候一定要确保一致性。假如字段在某个表中叫做
“agreement_number”，你就别在另一个表里把名字改成“ref1”。假如数据类型在一个表里
是整数，那在另一个表里可就别变成字符型了。记住，你干完自己活了，其它人还要用你数
据库呢。
— setanta
19. 仔细选择数字类型
在SQL 中使用smallint 和tinyint 类型要尤其小心，比如，假如你想看看月销售总额，你总额字
段类型是smallint，那么，假如总额超出了$32,767 你就不能进行计算操作了。
— egermain
20. 删除标识
在表中包含一个“删除标识”字段，这么就能够把行标识为删除。在关系数据库里不要单独删除
某一行；最好采取清除数据程序而且要仔细维护索引整体性。
— kol

21. 避免使用触发器
触发器功效通常能够用其它方法实现。在调试程序时触发器可能成为干扰。假如你确实需要采
用触发器，你最好集中对它文档化。
— kol
22. 包含版本机制
提议你在数据库中引入版本控制机制来确定使用中数据库版本。不管怎样你全部要实现这一要
求。时间一长，用户需求总是会改变。最终可能会要求修改数据库结构。即使你能够经过检
查新字段或索引来确定数据库结构版本，但我发觉把版本信息直接存放到数据库中不更为方
便吗？。
— Richard Foster
23. 给文本字段留足余量
ID 类型文本字段，比如用户ID 或定单号等等全部应该设置得比通常想象更大，因为时间不长你
多半就会因为要添加额外字符而难堪不已。比方说，假设你用户ID 为10 位数长。那你应该
把数据库表字段长度设为12 或13 个字符长。这算浪费空间吗？是有一点，但也没你想象
那么多：一个字段加长3 个字符在有1 百万条统计，再加上一点索引情况下才不过让整个数据
库多占据3MB 空间。但这额外占据空间却无需未来重构整个数据库就能够实现数据库规模
增加了。
— tlundin
24. 列命名技巧
我们发觉，假如你给每个表列名全部采取统一前缀，那么在编写SQL 表示式时候会得到大
大简化。这么做也确实有缺点，比如破坏了自动表连接工具作用，后者把公共列名同一些数
据库联络起来，不过就连这些工含有时不也连接错误嘛。举个简单例子，假设有两个表：
Customer 和Order。Customer 表前缀是cu_，所以该表内子段名以下：cu_name_id、
cu_surname、cu_initials 和cu_address 等。Order 表前缀是or_，所以子段名是：
or_order_id、or_cust_name_id、or_quantity 和or_description 等。
这么从数据库中选出全部数据SQL 语句能够写成以下所表示：
Select * from Customer, Order
Where cu_surname = "MYNAME"
and cu_name_id = or_cust_name_id
and or_quantity = 1;
在没有这些前缀情况下则写成这个样子：
Select * from Customer, Order
Where Customer.surname = "MYNAME"
and Customer.name_id = Order.cust_name_id
and Order.quantity = 1
第1 个SQL 语句没少键入多少字符。但假如查询包含到5 个表乃至更多列你就知道这个技巧
多有用了。
— Bryce Stenberg

第3 部分— 选择键和索引
1. 数据采掘要预先计划
我所在市场部门一度要处理8 万多份联络方法，同时填写每个用户必需数据（这绝对不是小
活）。我从中还要确定出一组用户作为市场目标。当我从最开始设计表和字段时候，我试图不
在主索引里增加太多字段方便加紧数据库运行速度。然后我意识到特定组查询和信息采掘
既不正确速度也不快。结果只好在主索引中重建而且合并了数据字段。我发觉有一个指示计划相
当关键——当我想创建系统类型查找时为何要采取号码作为主索引字段呢？我能够用传真号码
进行检索，不过它几乎就象系统类型一样对我来说并不关键。采取后者作为主字段，数据库更新
后重新索引和检索就快多了。
— hscovell
可操作数据仓库（ODS）和数据仓库（DW）这两种环境下数据索引是有差异。在DW 环境
下，你要考虑销售部门是怎样组织销售活动。她们并不是数据库管理员，不过她们确定表内
键信息。这里设计人员或数据库工作人员应该分析数据库结构从而确定出性能和正确输出之间
最好条件。
— teburlew
2. 使用系统生成主键
这一天类同技巧1，但我认为有必需在这里反复提醒大家。假如你总是在设计数据库时候采取
系统生成键作为主键，那么你实际控制了数据库索引完整性。这么，数据库和非人工机制就
有效地控制了对存放数据中每一行访问。
采取系统生成键作为主键还有一个优点：当你拥有一致键结构时，找到逻辑缺点很轻易。
— teburlew
3. 分解字段用于索引
为了分离命名字段和包含字段以支持用户定义报表，请考虑分解其它字段（甚至主键）为其组
成要素方便用户能够对其进行索引。索引将加紧SQL 和报表生成器脚本实施速度。比方说，
我通常在必需使用SQL LIKE 表示式情况下创建报表，因为 case number 字段无法分解为
year、serial number、case type 和defendant code 等要素。性能也会变坏。假如年度和类型字
段能够分解为索引字段那么这些报表运行起来就会快多了。
— rdelval
4. 键设计4 标准
· 为关联字段创建外键。
· 全部键全部必需唯一。
· 避免使用复合键。
· 外键总是关联唯一键字段。
— Peter Ritchie

5. 别忘了索引
索引是从数据库中获取数据最高效方法之一。95%数据库性能问题全部能够采取索引技术得到
处理。作为一条规则，我通常对逻辑主键使用唯一成组索引，对系统键（作为存放过程）采取
唯一非成组索引，对任何外键列采取非成组索引。不过，索引就象是盐，太多了菜就篌了。你
得考虑数据库空间有多大，表怎样进行访问，还有这些访问是否关键用作读写。
— tduvall
大多数数据库全部索引自动创建主键字段，不过可别忘了索引外键，它们也是常常使用键，比
如运行查询显示主表和全部关联表某条统计就用得上。还有，不要索引memo/note 字段，不
要索引大型字段（有很多字符），这么作会让索引占用太多存放空间。
— gbrayton
6. 不要索引常见小型表
不要为小型数据表设置任何键，假如它们常常有插入和删除操作就更别这么作了。对这些插入和
删除操作索引维护可能比扫描表空间消耗更多时间。
— kbpatel
7. 不要把社会保障号码（SSN）选作键
永远全部不要使用SSN 作为数据库键。除了隐私原因以外，须知政府越来越趋向于不准许把
SSN 用作除收入相关以外其它目标，SSN 需要手工输入。永远不要使用手工输入键作为主
键，因为一旦你输入错误，你唯一能做就是删除整个统计然后从头开始。
— teburlew
上个世纪70 年代我还在读大学时候，我记得那时SSN 还曾被用做学号，当然尽管这么做是非
法。而且大家也全部知道这是非法，但她们已经习惯了。以后，伴随盗取身份犯罪案件增
加，我现在大学校园正痛苦地从一大摊子数据中把SSN 删除。
— generalist
8. 不要用用户键
在确定采取什么字段作为表键时候，可一定要小心用户将要编辑字段。通常情况下不要
选择用户可编辑字段作为键。这么做会迫使你采取以下两个方法：
· 在创建统计以后对用户编辑字段行为施加限制。假如你这么做了，你可能会发觉你应用程
序在商务需求忽然发生改变，而用户需要编辑那些不可编辑字段时缺乏足够灵活性。当用
户在输入数据以后直到保留统计才发觉系统出了问题她们该怎么想？删除重建？假如统计不可
重建是否让用户走开？
· 提出部分检测和纠正键冲突方法。通常，费点精力也就搞定了，不过从性能上来看这么做
代价就比较大了。还有，键纠正可能会迫使你突破你数据和商业/用户界面层之间隔
离。
所以还是重提一句老话：你设计要适应用户而不是让用户来适应你设计。
— Lamont Adams
不让主键含有可更新性原因是在关系模式下，主键实现了不一样表之间关联。比如，
Customer 表有一个主键CustomerID，而用户定单则存放在另一个表里。Order 表主键可能

是OrderNo 或OrderNo、CustomerID 和日期组合。不管你选择哪种键设置，你全部需要在
Order 表中存放CustomerID 来确保你能够给下定单用户找到其定单统计。
假如你在Customer 表里修改了CustomerID，那么你必需找出Order 表中全部相关统计对其进
行修改。不然，有些定单就会不属于任何用户——数据库完整性就算完蛋了。
假如索引完整性规则施加到表一级，那么在不编写大量代码和附加删除统计情况下几乎不可能
改变某一条统计键和数据库内全部关联统计。而这一过程往往错误丛生所以应该尽可能避免。
— ljboast
9. 可选键有时可做主键
记住，查询数据不是机器而是人。
假如你有可选键，你可能深入把它用做主键。那样话，你就拥有了建立强大索引能力。这
样能够阻止使用数据库人不得不连接数据库从而合适过滤数据。在严格控制域表数据库
上，这种负载是比较醒目标。假如可选键真正有用，那就是达成了主键水准。
我见解是，假如你有可选键，比如国家表内state_code，你不要在现有不能变动唯一键上
创建后续键。你要做无非是创建毫无价值数据。比如以下例子：
Select count(*)
from address, state_ref
where
address.state_id = state_ref.state_id
and state_ref.state_code = 'TN'
我做法是这么：
Select count(*)
from address
where
and state_code = 'TN'
如你因为过分使用表后续键建立这种表关联，操作负载真得需要考虑一下了。
— Stocker
10. 别忘了外键
大多数数据库索引自动创建主键字段。但别忘了索引外键字段，它们在你想查询主表中统计
及其关联统计时每次全部会用到。还有，不要索引memo/notes 字段而且不要索引大型文本字段
（很多字符），这么做会让你索引占据大量数据库空间。。
— gbrayton

第4 部分— 确保数据完整性
1. 用约束而非商务规则强制数据完整性
假如你根据商务规则来处理需求，那么你应该检验商务层次/用户界面：假如商务规则以后发生变
化，那么只需要进行更新即可。
假如需求源于维护数据完整性需要，那么在数据库层面上需要施加限制条件。
假如你在数据层确实采取了约束，你要确保有措施把更新不能经过约束检验原因采取用户了解
语言通知用户界面。除非你 字段命名很冗长，不然字段名本身还不够。 — Lamont Adams
只要有可能，请采取数据库系统实现数据完整性。这不仅包含经过标准化实现完整性而且还
包含数据功效性。在写数据时候还能够增加触发器来确保数据正确性。不要依靠于商务层
确保数据完整性；它不能确保表之间（外键）完整性所以不能强加于其它完整性规则之上。
— Peter Ritchie
2. 分布式数据系统
对分布式系统而言，在你决定是否在各个站点复制全部数据还是把数据保留在一个地方之前应该
估量一下未来5 年或10 年数据量。当你把数据传送到其它站点时候，最好在数据库字段
中设置部分标识。在目标站点收到你数据以后更新你标识。为了进行这种数据传输，请写下
你自己批处理或调度程序以特定时间间隔运行而不要让用户在天天工作后传输数据。当地
拷贝你维护数据，比如计算常数和利息率等，设置版本号确保数据在每个站点全部完全一致。
— Suhair TechRepublic
3. 强制指示完整性
没有好措施能在有害数据进入数据库以后消除它，所以你应该在它进入数据库之前将其剔除。激
活数据库系统指示完整性特征。这么能够保持数据清洁而能迫使开发人员投入更多时间处
理错误条件。
— kol
4. 关系
假如两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置
成多对多关系。从现有多对一关系转变为多对多关系比一开始就是多对多关系要难得多。
— CS Data Architect
5. 采取视图
为了在你数据库和你应用程序代码之间提供另一层抽象，你能够为你应用程序建立专门
视图而无须非要应用程序直接访问数据表。这么做还等于在处理数据库变更时给你提供了更多
自由。
— Gay Howe

6. 给数据保有和恢复制订计划
考虑数据保有策略并包含在设计过程中，预先设计你数据恢复过程。采取能够公布给用户/开发
人员数据字典实现方便数据识别同时确保对数据源文档化。编写在线更新来“更新查询”供
以后万一数据丢失能够重新处理更新。
— kol
7. 用存放过程让系统做重活
处理了很多麻烦来产生一个含有高度完整性数据库处理方案以后，我所在团体决定封装部分
关联表功效组，提供一整套常规存放过程来访问各组方便加紧速度和简化用户程序代码开
发。在此期间，我们发觉3GL 编码器设置了全部可能错误条件，比如以下所表示：
SELECT Cnt = COUNT (*)
FROM [<Table>]
WHERE [<primary key column>] = <new value>
IF Cnt = 0
BEGIN
INSERT INTO [<Table>]
( [< primary key column>] )
VALUES ( <New value> )
END
ELSE
BEGIN
<indicate duplication error>
END
而一个非3GL 编码器是这么做：
INSERT INTO [<Table>]
( [< primary key column>] )
VALUES
( <New value> )
IF @@ERROR = 2627 -- Literal error code for Primary Key Constraint
BEGIN
<indicate duplication error>
END
第2 个程序简单多了，而且实际上，利用了我们给数据库功效。即使我个人不喜爱使用嵌入文
字（2627）。不过那样能够很方便地用一点预先处理来替换。数据库不只是一个存放数据地
方，它也是简化编码之地。
— a-smith
8. 使用查找
控制数据完整性最好方法就是限制用户选择。只要有可能全部应该提供给用户一个清楚价值
列表供其选择。这么将降低键入代码错误和误解同时提供数据一致性。一些公共数据尤其适
合查找：国家代码、状态代码等。
— CS Data Architect

第5 部分— 多种小技巧
1. 文档、文档、文档
对全部快捷方法、命名规范、限制和函数全部要编制文档。
— nickypendragon
采取给表、列、触发器等加注释数据库工具。是，这有点费事，但从长远来看，这么做对开
发、支持和跟踪修改很有用。
— chardove
取决于你使用数据库系统，可能有部分软件会给你部分供你很快上手文档。你可能期望先开
始在说，然后取得越来越多细节。或你可能期望周期性预排，在输入新数据同时伴随你
进展对每一部分细节化。不管你选择哪种方法，总要对你数据库文档化，或在数据库本身
内部或单独建立文档。这么，当你过了十二个月多时间后再回过头来做第2 个版本，你犯错机会
将大大降低。
— mrs_helm
2. 使用常见英语（或其它任何语言）而不要使用编码
为何我们常常采取编码（比如9935A 可能是墨水笔供给代码，4XF788-Q 可能是帐目编
码）？理由很多。不过用户通常全部用英语进行思索而不是编码。工作5 年会计或许知道
4XF788-Q 是什么东西，但新来可就不一定了。在