必然要记着已往的履历教导！我们开拓人员还应该通过度享本身的体会和履历相互辅佐。纵然用户认为他们再也不需要什么支持了，我们也应该对他们举办这方面的教诲，我们都曾经面对过这样的时刻“当初要是这么做了该多好..”。
在物理实践之前举办逻辑设计
在深入物理设计之前要先举办逻辑设计。跟着大量的 CASE 东西不绝涌现出来，你的设计也可以到达相当高的逻辑水准，你凡是可以从整体上更好地相识数据库设计所需要的方方面面。
相识你的业务
在你百分百地确定系统从客户角度满意其需求之前不要在你的 ER（实体干系）模式中插手哪怕一个数据表（怎么，你还没有模式？那请你参看能力 9）。相识你的企业业务可以在今后的开拓阶段节省大量的时间。一旦你明晰了业务需求，你就可以本身做出很多决定了。
一旦你认为你已经明晰了业务内容，你最好同客户举办一次系统的交换。回收客户的术语而且向他们表明你所想到的和你所听到的。同时还应该用大概、将会和必需等词汇表达出系统的干系基数。这样你就可以让你的客户更正你本身的领略然后做好下一步的 ER 设计。
建设数据字典和 ER 图表
必然要花点时间建设 ER 图表和数据字典。个中至少应该包括每个字段的数据范例和在每个表内的主外键。建设 ER 图表和数据字典确实有点费时但对其他开拓人员要相识整个设计却是完全须要的。越早建设越能有助于制止此后头临的大概杂乱，从而可以让任何相识数据库的人都明晰如何从数据库中得到数据。
有一份诸如 ER 图表等最新文档其重要性如何强调都不外分，这对表白表之间干系很有用，而数据字典则说明白每个字段的用途以及任何大概存在的别名。对 SQL 表达式的文档化来说这是完全须要的。
建设模式
一张图表胜过千言万语：开拓人员不只要阅读和实现它，并且还要用它来辅佐本身和用户对话。模式有助于提高协作效能，这样在先期的数据库设计中险些不行能呈现大的问题。模式不必弄的很巨大；甚至可以简朴得手写在一张纸上就可以了。只是要担保其上的逻辑干系此后能发生效益。
从输入输出下手
在界说数据库表和字段需求（输入）时，首先应查抄现有的可能已经设计出的报表、查询和视图（输出）以抉择为了支持这些输出哪些是须要的表和字段。举个简朴的例子：如果客户需要一个报表凭据邮政编码排序、分段和求和，你要担保个中包罗了单独的邮政编码字段而不要把邮政编码糅进地点字段里。
报表能力
要相识用户凡是是如何陈诉数据的：批处理惩罚照旧在线提交报表？时距离断是天天、每周、每月、每个季度照旧每年？假如需要的话还可以思量建设总结表。系统生成的主键在报表中很难打点。用户在具有系统生成主键的表内用副键举办检索往往会返回很多反复数据。这样的检索机能较量低并且容易引起杂乱。
领略客户需求
看起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度思量）。不要依赖用户写下来的需求，真正的需求在客户的脑壳里。你要让客户表明其需求，并且跟着开拓的继承，还要常常询问客户担保其需求仍然在开拓的目标之中。一个稳定的真理是：“只有我瞥见了我才知道我想要的是什么”一定会导致大量的返工，因为数据库没有到达客户从来没有写下来的需求尺度。而更糟的是你对他们需求的表明只属于你本身，并且大概是完全错误的。
第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 记录来反应新头衔的变革，不外这样一来在时间上无法跟踪
小我私家所处位置的详细时间。
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 部门 - 选择键和索引