数据库设计经验

 

2004-11-24微软技能博客

作者: wjk.net(转载)

一个中标的管理连串,是由:[50% 的业务 + 50% 的软件] 所组成,而 50%
的功成名就软件又有 [25% 的数据库 + 25%的先后]
所结合,数据库设计的三六九等是一个紧要。如果把商家的数目比做生命
所必需的血液,那么数据库的规划就是采纳中最敬爱的一部分
。有关数据库设计的材料汗牛充栋,大学学位课程里也有专门的叙说
。然而,就像大家反复强调的那样,再好的老师也比但是经验的教诲
。所以自己归咎历年来所走的弯路及认知,并在网上找了些对数据库设
计颇有功力的专业人员给我们传授一些陈设数据库的技艺和阅历
。精选了其中的60
个极品技巧,并把那些技能编写成了本文,为了方便索引其内容划分 为 5
个部分:

第 1 局地 – 设计数据库以前

这一部分罗列了 12 个着力技能,包含取名规范和分明作业须要等。

第 2 片段 – 设计数据库表

总共 24 个指南性技巧,涵盖表内字段设计以及相应幸免的大规模难题等。

第 3 部分 – 选择键

怎么选拔键呢?那里有 10 个技巧专门提到系统生成的主键的没错用法,还有啥时以及怎么着索引字段以得到最佳质量等。

必发娱乐最新官方网址,第 4 部分 – 保障数据完整性

议论什么保持数据库的不可磨灭和矫健,如何把风险数据回落到细微程度 。

第 5 部分 – 各样小技巧

不包蕴在上述 4
个部分中的其余技术,五花八门,有了它们希望您的数据库开发工作
会更自在一些。

第 1 有的 – 设计数据库此前

着眼现有条件

在布署一个新数据库时,你不单应该精心琢磨业务需求而且还要考察
现有的系统。大部分数据库项目都不是从头初阶建立的;平常,机构内总会设有用来满足特定需要的存活系统(可能没有兑现全自动
总计)。明显,现有系统并不周全,否则你就不要再建立新系统了
。不过对旧连串的研究可以让您意识一些或许会忽视的细微问题。一般的话,考察现有系统对你相对有补益。

概念标准的靶子命名规范

自然要定义数据库对象的命名规范。对数据库表来说
,从体系一起头就要确定表名是选取复数如故单数格局。其余还要给表的别名定义不难规则(比方说,如若表名是一个单词
,别名就取单词的前4
个字母;假如表名是五个单词,就各取三个单词的前四个字母组成 4
个字母长的别名;倘诺表的名字由
3个单词组成,你不妨起来多少个单词中各取一个然后从最后一个单词中
再取出八个假名,结果仍旧构成
4字母长的别名,其余依次类推)对工作用表来说,表名能够增加前缀
WORK_末尾附上拔取该表的应用程序的名字。表内的列[字段
]要针对键选用一整套规划规则。比如,假如键是数字类型 ,你可以用
_N作为后缀;如果是字符类型则足以运用
_C后缀。对列[字段]名应当运用专业的前缀和后缀。再如
,假使你的表里有很多”money”字段,你不妨给每个列[字段 ]日增一个
_M后缀。还有,日期列[字段]最好以 D_ 作为名字打头。

反省表名、报表名和查询名之间的命名规范。你或许会快速就被那个区其余数据库要素的名目搞糊涂了。借使你坚定不移合并地命名那些数据
库的不比组成部分,至少你应该在这几个目的名字的起来用Table、Query 或者
Report 等前缀加以差别。

假如利用了 Microsoft Access,你可以用 qry、rpt、tbl 和 mod
等标志来标识对象(比如tbl_Employees)。我在和 SQL Server
打交道的时候还用过 tbl 来索引表,但自我用 sp_company (现在用
sp_feft_)标识存储进程,因为在一些时候倘诺我发觉了更
好的拍卖方法往往会保留好多少个拷贝。我在落到实处 SQL Server 2000 时用udf_
(或者类似的标记)标识我编写的函数。

工欲善其事, 必先利其器

选拔理想的数据库设计工具,比如:SyBase 集团的 PowerDesign,她支持PB、VB、Delphe 等语言,通过 ODBC可以连接市面上流行的 30 多个数据库,包蕴dBase、FoxPro、VFP、SQL Server 等,今后有空子我将重视介绍PowerDesign
的施用。

获取数据格局资源手册

正在寻求示例格局的人可以阅读《数据形式资源手册》一书,该书由 Len
Silverston、W. H. Inmon 和 Kent Graziano
编写,是一本值得拥有的极品数据建模图书。该书概括的章节涵盖种种数据领域,比如人口、机构和行事效果等。其余的您仍能参见:
[1]萨师煊王珊著数据库系统概论(第二版)高等教育出版社 1991、[2][美]
Steven M.Bobrowski 著 Oracle 7
与客户/服务器统计技术从入门到明白刘建元等译电子工业出版社,1996、[3]周中元音讯种类建模方法(下)电子与音信化1999年第3期,1999畅想将来,但不可忘了过去的训诫我发现询问用户如何对待未来急需变动格外有效。那样做可以达成两个目标:首先,你可以清楚地询问应用设计在哪个地点应该更具灵活
性以及怎么样幸免品质瓶颈;其次,你明白暴发事先没有规定的须要变
更时用户将和您一样感到吃惊。

毫无疑问要铭记过去的经验教训!咱们开发人员还应当经过分享温馨的体
会和阅历互相帮衬。就算用户觉得他们再也不需要怎么着帮助了
,我们也相应对她们开展那上边的指点,大家都早已面临过那样的时
刻”当初要是那般做了该多好..”。

在物理实践从前开展逻辑设计

在深深物理设计前边要先举行逻辑设计。随着大气的
CASE工具不断涌现出来,你的设计也足以达到相当高的逻辑水准
,你见惯不惊可以从全部上更好地打听数据库设计所要求的一体。

问询您的事情

在你百分百地确定系统从客户角度满意其必要此前毫无在你的
ER(实体关系)方式中投入哪怕一个数据表(怎么,你还没有方式?那请您参看技巧9)。精通你的集团工作可以在今后的开发阶段节约大批量的时间
。一旦你显然了工作须求,你就足以友善做出过多裁定了。

若是你认为你曾经妇孺皆知了政工内容,你最好同客户拓展一次系统的调换。采纳客户的术语并且向他们说明你所想到的和您所听到的
。同时还相应用可能、将会和必须等词汇表达出系统的涉及基数
。那样您就足以让您的客户校对你协调的明亮然后做好下一步的ER 设计。

创办数量字典和 ER 图表

自然要花点时间创建 ER
图表和数量字典。其中至少应当包涵每个字段的数据类型和在各类表
内的主外键。创设 ER
图表和数目字典确实有点困难但对其他开发职员要询问整个安排却是
完全须要的。越早创立越能有助于防止事前边临的也许混乱
,从而可以让其余问询数据库的人都醒目怎么着从数据库中收获数据。

有一份诸如 ER
图表等风靡文档其首要如何强调都不过分,那对注脚表之间涉及很
有用,而数据字典则证实了各样字段的用处以及别的可能存在的别名 。对SQL
表明式的文档化来说那是完全须求的。

创办格局

一张图片胜过万语千言:开发人员不仅要读书和兑现它
,而且还要用它来扶持协调和用户对话。方式有助于增高同盟功能,那样在优先的数据库设计中大概不能出现大的问题。形式不必弄的很复杂;甚至足以概括到手写在一张纸上就可以了
。只是要有限支持其上的逻辑关系今后能爆发功用。

从输入输出出手

在定义数据库表和字段须求(输入)时,首先应反省现有的或者曾经
设计出的表格、查询和视图(输出)以控制为了协助那么些输出哪些是
要求的表和字段。举个简单的例子:假若客户须求一个报表依据邮编排序、分段和求和,你要有限支撑内部囊括了单独的邮编字段而
不要把邮编糅进地址字段里。

报表技巧

要精通用户一般是何等报告数量的:批处理仍旧在线提交报表
?时间间隔是每一天、周周、每月、每个季度或者年年
?要是要求的话还足以考虑成立总计表。系统生成的主键在表格中很
难管理。用户在颇具系统生成主键的表内用副键进行搜索往往会再次来到许多再一次数据。那样的摸索质量比较低而且不难滋生混乱。

清楚客户须要

看起来这应该是有目共睹的事,但须要就是出自客户
(那里要从里头和表面客户的角度考虑)。不要借助用户写下去的需求,真正的需求在客户的尾部里。你要让客户解释其必要,而且趁机开发的一而再,还要时不时询问客户保证其要求如故在开发的
目标中间。一个不变的真谛是:”唯有自身看见了本人才领会自家想要的是
什么”必然会造成大气的返工,因为数据库没有直达客户向来不曾写
下来的需要标准。而更糟的是你对他们须要的分解只属于您自己
,而且恐怕是一点一滴错误的。

第 2 有的 – 设计表和字段

检查各个变动

本身在设计数据库的时候会考虑到什么数据字段未来恐怕会发生变更
。比方说,姓氏就是这么(注意是西方人的姓氏,比如女性结婚后从
夫姓等)。所以,在创造种类存储客户音讯时,我赞成于在单身的一
个数据表里存储姓氏字段,而且还叠加早先日和终止日等字段
,那样就足以跟踪这一数据条目标变动。

动用有含义的字段名

有四次自家参预开发过一个门类,其中有从其余程序员那里继承的程序
,那多少个程序员喜欢用屏幕上浮现数据提醒用语命名字段,那也不赖
,但不幸的是,她还喜欢用部分始料不及的命名法,其命名选拔了匈牙利命名和控制序号的重组形式,比如cbo1、txt2、txt2_b 等等。
除非您在采纳只面向您的缩写字段名的系统,否则请尽可能地把字段
描述的敞亮些。当然,也别做过度了,比如Customer_Shipping_Address
_Street_Line_1,就算很富有表达性
,但没人愿意键入这么长的名字,具体规范就在您的握住中。
利用前缀命名。如若三个表里有很多同等档次的字段(比如
FirstName),你不妨用特定表的前缀(比如 CusLastName)来增援您标识字段。

时效性数据应包蕴”近来翻新日期/时间”字段。时间标记对寻找数
据难点的来由、按日期重新处理/重载数据息争除旧数据尤其有用。
规格和数码驱动数据的尺度不仅利于了友好同时也惠及了其余人。比方说
,若是你的用户界面要拜访外部数据源(文件、XML
文档、其余数据库等),你不妨把相应的连年和路径音信囤积在用户
界面协助表里。还有,假如用户界面执行工作流之类的职务(发送邮件、打印信笺、修改记录状态等),那么爆发工作流的数据
也足以存放在数据库里。预先安顿总须求提交努力,但若是这一个经过
选取数据驱动而非硬编码的艺术,那么策略改变和保安都会方便得多
。事实上,就算经过是数额驱动的,你就足以把优秀大的权责推给用
户,由用户来有限辅助和谐的工作流进程。

规则不可能过头

对那么些不熟知标准化一词(normalization)的人而言
,标准化可以有限协理表内的字段都是最基础的元素,而这一方式促进
消除数据库中的数据冗余。标准化有一些种形式,但Third 诺玛l
Form(3NF)平常被认为在性质、伸张性和数据完整性方面达
到了最好平衡。一句话来说,3NF 确定:
* 表内的每一个值都只可以被发挥一回。
* 表内的每一行都应当被唯一的标识(有唯一键)。
* 表内不应当储存依赖于其余键的非键音讯。
遵循 3NF 标准的数据库具有以下特点:有一组表专门存放通过键连接起来的关
联数据。比方说,某个存放客户及其有关定单的 3NF
数据库就可能有八个表:Customer 和 Order。Order
表不带有定单关联客户的其余信息,但表内会存放一个键值 ,该键指向Customer
表里含有该客户信息的那一行。
更高层次的原则也有,但更标准是不是就决然更好吧?答案是不肯定
。事实上,对少数品种以来,甚至就连 3NF 都可能给数据库引入太高的扑朔迷离。

为了功能的案由,对表不进行标准有时也是要求的
,那样的例子很多。曾经有个开发餐饮分析软件的活就是用非标准化
表把询问时间从平均
40秒下降到了两秒左右。固然我只可以如此做,但自我绝不把数据表的非
标准化当作理所当然的陈设性理念。而现实的操作不过是一种派生
。所以如果表出了难题再度暴发非标准化的表是完全可能的。

Microsoft Visual FoxPro 报表技巧

若是您正在利用 Microsoft Visual
FoxPro,你可以用对用户自己的字段名来代替编号的名称 :比如用 Customer
Name 代替 txtCNaM。那样,当你用向导程序 [Wizards,广西人称为’天使’]
创制表单和表格时,其名字会让那个不是程序员的人更便于阅读。

不活跃或者不拔取的提醒符

增加一个字段表示所在笔录是不是在作业中不再活跃挺有用的
。不管是客户、员工依然此外哪个人,这样做都能牵动再运行查询
的时候过滤活跃或者不活跃状态。同时还免去了新用户在利用数据时
所面临的有的题材,比如,某些记录可能不再为他们所用
,再删除的时候能够起到早晚的防备功用。

使用角色实体定义属于某项目的列[字段]

在必要对属于特定类型或者持有一定角色的东西做定义时
,可以用角色实体来创设特定的年华关系关系,从而得以兑现自我文 档化。
此地的意义不是让 PERSON 实体带有 Title 字段,而是说,为啥不用 PERSON
实体和 PERSON_TYPE实体来叙述人士呢?比方说,当 John 史密斯, Engineer
提高为 John Smith, Director 乃至末了爬到John Smith, CIO
的要职,而具备你要做的可是是改变八个表 PERSON 和
PERSON_TYPE之间关系的键值,同时扩展一个日子/时间字段来了然变化是曾几何时暴发的。那样,你的 PERSON_TYPE 表就包罗了有着 PERSON的也许类型,比如
Associate、Engineer、Director 、CIO 或者 主管 等。
还有个代表方式就是改变 PERSON
记录来体现新头衔的变通,不过如此一来在岁月上不可能跟踪个人所处
地方的有血有肉日子。

动用常用实体命名机构数据

团队数据的最不难易行方法就是运用常用名字,比如:PERSON
、ORGANIZATION、ADDRESS 和
PHONE等等。当您把这一个常用的貌似名字组合起来如故创立特定的相应副实
体时,你就获得了和睦用的新鲜版本。早先的时候利用一般术语的主要原因在于拥有的现实用户都能对抽象事物具体化。
有了这一个抽象意味,你就可以在第 2
级标识中应用自己的非正规名称,比如,PERSON
可能是Employee、Spouse、Patient、Client 、Customer、Vendor 或者
Teacher等。同样的,ORGANIZATION 也恐怕是
MyCompany、MyDepartment、Competi tor、Hospital、Warehouse、Governm ent
等。最后ADDRESS 可以切实为 Site、Location、Home、Work、Client
、Vendor、Corporate 和FieldOffice 等。
运用一般抽象术语来标识”事物”的类型可以让你在关联数据以满意业务必要地点获取巨大的一帆风顺,同时这样做仍能一目明白下降数据存
储所需的冗余量。

用户来源世界各州

在布署用到网络或者具有任何国际特性的数据库时,一定要牢记超过一半国家都有例外的字段格式,比如邮编等,有些国家
,比如新西兰就不曾邮编一说。

数码再度要求动用分立的数据表

若果你发现自己在再一次输入数据,请创设新表和新的关联。
每个表中都应该加上的 3 个有效的字段
* dRecordCreationDate,在 VB 下默认是 Now(),而在 SQL Server 下默许为
GETDATE()
* sRecordCreator,在 SQL Server 下默许为 NOT NULL DEFAULT USER
* nRecordVersion,记录的版本标记;有助于准确验证 记录中冒出 null
数据仍旧丢失数据的原委
对地点和电话接纳三个字段
叙述街道地址就指日可待一行记录是不够的。Address _Line1、Address_Line2 和
Address_Line3
可以提供更大的一帆风顺。还有,电话号码和邮件地址最好拥有自己的
数据表,其间具有本身的连串和符号序列。

过火标准化可要小心,那样做也许会导致质量上边世问题。纵然地方和电话表分离常常可以达到最佳状态,不过如若急需平常访问那类音讯,或许在其父表中存放”首选”新闻(比如
Customer 等)更为稳妥些。非标准化和增速访问时期的投降是有一定意义的。

应用三个称呼字段

自身以为很吃惊,许三人在数据库里就给
name留一个字段。我觉着唯有刚入门的开发人士才会那样做
,但实则网上那种做法尤其广阔。我指出应该把姓氏和名字当作八个字段来处理,然后在查询的时候再把他们结合起来。

本人最常用的是在同一表中开创一个总结列[字段],通过它可以活动
地连接标准化后的字段,那样数据变动的时候它也跟着变。可是,那样做在选用建模软件时得很灵活才行。同理可得,拔取连接字段的格局可以有效的割裂用户使用和开发人员界面。
幸免大小写混用的目标名和特殊字符过去最令自己发脾气的事务之一就是数据库里有高低写混用的对象名
,比如 CustomerData。这一标题从 Access 到
Oracle数据库都设有。我不爱好使用那种大小写混用的对象命名方法
,结果还只能手工修改名字。想想看,那种多少库
/应用程序能混到接纳更强大数据库的那一天吧?采纳任何大写而且
包括下划符的名字拥有更好的可读性(CUSTOMER_DATA
),相对不要在目的名的字符之间留空格。

小心保留词

要保管你的字段名没有和保留词、数据库系统或者常用访问方法争论,比如,近年来我编写的一个 ODBC 连接程序里有个表,其中就用了
DESC作为讲明字段名。后果同理可得!DESC 是 DESCENDING
缩写后的保留词。表里的一个 SELECT
*语句倒是能用,但自身得到的却是一大堆并非用处的信息。

保证字段名和花色的一致性

在命名字段并为其指定数据类型的时候自然要保管一致性
。即使字段在某个表中叫做”agreement_number”
,你就别在另一个表里把名字改成”ref1″。假若数据类型在一
个表里是整数,那在另一个表里可就别变成字符型了。记住
,你干完自己的活了,其余人还要用你的数据库呢。

周全拔取数字类型

在 SQL 中行使 smallint 和 tinyint
类型要更加小心,比如,要是你想看看月销售总额,你的总额字段类
型是smallint,那么,假使总额超越了 $32,767 你就不可以开展测算操作了。

去除标记

在表中涵盖一个”删除标记”字段,那样就可以把行标记为除去
。在关全面据库里不要独立删除某一行;最好使用清除数据程序同时
要仔细维护索引全体性。

避免使用触发器

触发器的功用平日可以用其他方法贯彻。在调试程序时触发器可能成
为苦恼。如果你真正要求运用触发器,你最好集中对它文档化。
带有版本机制提议您在数据库中引入版本控制机制来规定使用中的数据库的版本
。无论如何你都要完成这一渴求。时间一长,用户的必要延续会变动
的。最后可能会要求修改数据库结构。即使你可以因此检查新字段或
者索引来确定数据库结构的版本,但自己发现把版本新闻直接存放到数
据库中不更为便利啊?

给文本字段留足余量

ID 类型的文件字段,比如客户
ID或定单号等等都应有设置得比相似想象更大,因为日子不长你多半就
会因为要添加额外的字符而狼狈不已。比方说,如若你的客户 ID 为
10位数长。那您应该把数据库表字段的尺寸设为 12 或者 13
个字符长。那算浪费空间啊?是有少数,但也没你想象的那么多 :一个字段加长
3个字符在有 1 百万条记下,再增进一些索引的意况下才可是让一切数据库多占用
3MB的空中。但那额外占据的空中却不必未来重构整个数据库就可以兑现
数据库规模的增加了。身份证的号码从 15 位变成 18
位就是最好和最优伤的例证。

列[字段]命名技巧

咱们发现,假若你给各类表的列[字段]名都采纳统一的前缀 ,那么在编制
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_denoscription
等。
诸如此类从数据库中选出全体数据的 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
个表乃至更加多的列[字段]您就了然这一个技能多有用了。

第 3 部分 – 选取键和目录

数码采掘要预先布置

我所在的某一客户单位早已要处理
8万多份联系格局,同时填写每个客户的必不可少数据(那相对不是小活)
。我从中还要确定出一组客户作为市场目标。当自身从最发轫设计表和
字段的时候,我打算不在主索引里增添太多的字段以便加快数据库的
运行速度。然后我意识到特定的组查询和新闻采掘既不确切速度也不
快。结果只可以在主索引中重建而且合并了数码字段。我意识有一个提示陈设非凡主要——当自身想创立系统项目查找时怎么要利用号码作
为主索引字段呢?我可以用传真号码举办搜索,但是它大概就象系统
类型一样对自家的话并不重大。采取后者作为主字段,数据库更新后重
新索引和查找就快多了。

可操作数据仓库(ODS)和数据仓库(DW)那二种环境下的多寡
索引是有距离的。在
DW环境下,你要考虑销售机构是哪些社团销售移动的。他们并不是数量
库管理员,可是她们确定表内的键音信。那里设计人士或者数据库工
作人士应当分析数据库结构从而确定出品质和不利输出之间的极品条 件。

利用系统生成的主键

这类同技术 1,但自身觉得有必不可少在此地再度提示大家。假诺你总是在统筹数据库
的时候利用系统生成的键作为主键,那么您实在决定了数据库的索引
完整性。那样,数据库和非人工机制就使得地决定了对存储数据中每
一行的拜会。
使用系统生成键作为主键还有一个亮点:当您所有同样的键结构时
,找到逻辑缺陷很不难。

解释字段用于索引

为了分离命名字段和含有字段以接济用户定义的报表
,请考虑分解其余字段(甚至主键)为其构成要素以便用户可以对其
进行索引。索引将加快SQL和表格生成器脚本的推行进程。比方说,我日常在必得利用 SQL LIKE
表明式的动静下开创报表,因为 case number 字段不能分解为year、serial
number、case type 和 defendant
code等要素。品质也会变坏。假诺年度和花色字段可以解释为索引字段那
么那几个报表运行起来就会快多了。

键设计 4 原则

* 为涉嫌字段创造外键。
* 所有的键都必须唯一。
* 防止接纳复合键。
* 外键总是关联唯一的键字段。

别忘了索引

目录是从数据库中获取数据的最疾速方式之一。95%的数据库品质难题都得以选用索引技术取得缓解。作为一条规则
,我平时对逻辑主键使用唯一的成组索引,对系统键(作为存储过程)接纳唯一的非成组索引,对其他外键列[字段]采纳非成组索引
。但是,索引就象是盐,太多了菜就咸了。你得考虑数据库的上空有
多大,表如何举行访问,还有那么些访问是不是主要用作读写。

绝一大半数据库都引得自动创制的主键字段,可是可别忘了索引外键
,它们也是平日利用的键,比如运行查询突显主表和兼具关联表的某
条记下就用得上。还有,不要索引memo/note
字段,不要索引大型字段(有过多字符),那样作会让索引占用太多
的仓储空间。
并非索引常用的小型表不要为小型数据表设置任何键,假若它们常常有插入和删除操作就更
别那样作了。对这么些插入和删除操作的目录维护可能比扫描表空间消
耗越多的时刻。
不用把社会有限支撑号码(SSN)或身份证编号(ID)选作键。
世代都休想拔取 SSN 或 ID
作为数据库的键。除了隐衷原因以外,须知政党越来越趋向于不准许 把 SSN 或
ID
用作除收入有关以外的其它目的,SSN 或
ID须要手工输入。永远不要使用手工输入的键作为主键
,因为只要您输入错误,你唯一能做的就是去除所有记录然后初叶开 始。

自己在破解旁人的顺序时候,我看出不少人把 SSN 或
ID还曾被用做序列号,当然固然那样做是不法的。而且人们也都知晓这是私自的,但他俩已经数见不鲜了。后来,随着盗取身份犯罪案件的增多
,我现在的同行正痛苦地从一大摊子数据中把 SSN 或 ID 删除。

毫不用用户的键

在规定采取什么字段作为表的键的时候,可一定要小心用户即将编辑
的字段。平常的情形下不要挑拔取户可编制的字段作为键
。那样做会迫使你接纳以下多个办法:
* 在创立记录之后对用户编辑字段的表现施加限制。如若你这么做了
,你也许会意识你的应用程序在商务须求旱地拔葱,而用户需要编制这一个不可编辑的字段时缺少丰裕的灵活性
。当用户在输入数据之后直到保存记录才发觉系统出了难题他们该怎
么想?删除重建?要是记录不可重建是不是让用户走开?
* 提出一些检测和校订键争辨的措施。平常,费点精力也就搞定了
,可是从质量上来看这么做的代价就比较大了。还有
,键的改正或者会迫使你突破你的数码和经贸/用户界面层之间的隔 离。
从而依旧重提一句老话:你的陈设要适于用户而不是让用户来适应你 的筹划。

不让主键具有可更新性的原故是在事关形式下,主键落成了不一样表之
间的涉嫌。比如,Customer
表有一个主键CustomerID,而客户的定单则存放在另一个表里 。Order
表的主键可能是 OrderNo 或者
OrderNo、CustomerID和日期的三结合。不管你接纳哪个种类键设置,你都亟待在 Order
表中存放 CustomerID 来保管你可以给下定单的用户找到其定单记录。
如果你在 Customer 表里修改了 CustomerID,那么您必须找出
Order表中的所有相关记录对其进展改动。否则,有些定单就会不属于其他客户——数据库的完整性即便完蛋了。
倘使索引完整性规则施加到表超级,那么在不编写多量代码和叠加删
除记录的动静下大概不容许改动某一条记下的键和数据库内所有关联
的记录。而这一进度反复错误丛生所以应该尽量幸免。

可选键(候选键)有时可做主键

记住,查询数据的不是机械而是人。
如果你有可选键,你或许一发把它用做主键。那样的话
,你就具有了树立强有力索引的力量。那样可以阻挡使用数据库的人不
得不连续数据库从而方便的过滤数据。在严刻控制域表的数据库上
,那种负荷是相比较显明的。假诺可选键真正有用,那就是达标了主键 的档次。
自己的视角是,借使你有可选键,比如国家表内的state_code,你绝不在现有不能更改的绝无仅有键上创设后续
的键。你要做的一味是创设毫无价值的数目。如你因为过于使用表的
后续键[别名]确立那种表的涉嫌,操作负载真得须要考虑一下了。

别忘了外键

绝半数以上数据库索引自动创制的主键字段。但别忘了索引外键字段
,它们在你想查询主表中的记录及其关联记录时老是都会用到。还有
,不要索引memo/notes
字段而且不要索引大型文本字段(许多字符),那样做会让你的索引
占据大批量的数据库空间。

第 4 部分 – 有限支持数据的完整性

用约束而非商务规则强制数据完整性

一旦您根据商务规则来拍卖需要,那么你应当检查商务层次
/用户界面:假设商务规则之后发生变化,那么只必要进行翻新即可
。如果须求来自维护数据完整性的内需,那么在数据库层面上需求施
加限制条件。假设您在数据层确实接纳了约束,你要保管有艺术把更
新不可以经过自律检查的因由选取用户了然的言语通知用户界面
。除非您的字段命名很冗长,否则字段名本身还不够。

一旦有可能,请选取数据库系统贯彻数量的完整性。那不只包罗经过
标准化落成的完整性而且还包含数据的成效性。在写多少的时候还能增添触发器来保险数据的正确。不要借助于商务层有限支撑数据完整
性;它不可以保险表之间(外键)的完整性所以无法强加于其余完整性 规则之上。

分布式数据系统

对分布式系统而言,在您决定是不是在逐一站点复制所有数据依旧把数
据保存在一个地点此前应当预计一下前途 5 年或者 10
年的数据量。当您把多少传送到其余站点的时候,最好在数据库字段
中设置有些符号。在目标站点收到你的数量未来更新您的标记
。为了拓展那种数据传输,请写下你协调的批处理如故调度程序以特
定时间间隔运行而毫不让用户在天天的行事后传输数据
。本地拷贝你的保安数据,比如计算常数和利息等
,设置版本号有限支撑数据在每个站点都完全一致。

强制提醒完整性(参照完整性?)

没有好法子能在损伤数据进入数据库之后消除它,所以您应该在它进
入数据库此前将其删除。激活数据库系统的指令完整性特性
。那样可以保持数据的清新而能强迫开发人员投入越多的时光处理错误条件。

关系

一旦七个实体之间存在多对一提到,而且还有可能转正为多对多涉及
,那么你最好一发端就设置成多对多关系。从现有的多对一关系变化
为多对多关系比一初阶就是多对多关系要难得多。

利用视图

为了在你的数据库和您的应用程序代码之间提供另一层抽象
,你可以为你的应用程序建立专门的视图而无需非要应用程序直接访
问数据表。那样做还卓越在拍卖数据库变更时给您提供了越多的自由 。

给多少颇具和死灰复燃制定陈设

设想数据有所策略并带有在设计进程中,预先设计你的数据苏醒进程。选拔可以揭晓给用户/开发人员的多少字典达成方便的多寡识别同
时有限扶助对数据源文档化。编写在线更新来”更新查询
“供将来万一数量丢失可以重新处理更新。
用存储进度让系统做重活解决了好多劳动来爆发一个持有莫大完整性的数据库解决方案之后
,我决定封装一些关联表的作用组,提供一整套正规的囤积进程来访
问各组以便加火速度和简化客户程序代码的开支。数据库不仅是一个
存放数据的地方,它也是简化编码之地。

选用查找

控制数据完整性的特等格局就是限量用户的选项。只要有可能都应有
提要求用户一个清楚的市值列表供其选拔。那样将缩减键入代码的错
误和误解同时提供数据的一致性。某些公共数据尤其符合查找
:国家代码、状态代码等。

第 5 部分 – 各类小技巧

文档、文档、文档

对具有的连忙方式、命名规范、限制和函数都要编制文档。

应用给表、列[字段]、触发器等加注释的数据库工具。是的
,这有点费事,但从深切来看,这样做对开发、协理和跟踪修改至极 有用。

在于你利用的数据库系统,可能有局地软件会给您有的供您火速上
手的文档。你也许希望先起来在说,然后拿走进一步多的细节
。或者你可能希望周期性的预排,在输入新数据同时随着你的进展对
每一有的细节化。不管您选拔哪类艺术,总要对你的数据库文档化
,或者在数据库自身的内部照旧独立建立文档。那样
,当你过了一年多时间后再回过头来做第2 个版本,你犯错的机遇将大大缩小。

动用常用土耳其(Turkey)语(或者其余任何语言)而毫不采取编码

何以我们平常应用编码(比如 9935A
可能是’Budweiser’的供应代码,4XF788-Q可能是帐目编码)?理由很多。然而用户平常都用德语进行思想而不
是编码。工作 5 年的出纳员或许知道
4XF788-Q是怎么样东西,但新来的可就不必然了。在创设下拉菜单、列表
、报表时最好根据保加利亚共和国(The Republic of Bulgaria)语名排序。假诺你要求编码,那你能够在编码旁
附上用户知道的英语。

封存常用音信

让一个表专门存放一般数据库新闻很是管用。我常在那几个表里存放数
据库当前版本、如今检讨/修复(对FoxPro)、关联设计文档的名目、客户等音讯。那样可以已毕一种不难机制跟踪数据库,当客户抱怨他们的数码库
没有高达梦想的必要而与你关系时,那样做对非客户机 /服务器环境更加有用。

测试、测试、反复测试

树立或者修订数据库之后,必须用用户新输入的数据测试数据字段
。最紧要的是,让用户展开测试并且同用户一起保障你挑选的数目类
型满意商业要求。测试需求在把新数据库投入实际服务此前已毕。

自我批评安顿

在支付期间检查数据库设计的常用技术是因此其所支撑的应用程序原
型检查数据库。换句话说,针对每一种最后表明数据的原型应用
,保障你检查了数据模型并且查看怎么着取出数据。

Microsoft Visual 福克斯Pro 设计技术

对复杂的 Microsoft Visual
FoxPro数据库应用程序而言,可以把所有的主表放在一个数据库容器文件里
,然后增添其它数据库表文件和装载同原有数据库有关的特殊文件
。依据须要用这么些文件一连到主文件中的主表。比如数据输入
、数据索引、计算分析、向管理层或者政党部门提供报表以及各项只
读查询等。这一主意简化了用户和组权限的分配,而且有益于应用程
序函数(存储进度)的分组和细分,从而在先后必须修改的时候不难 管理。

发表评论

电子邮件地址不会被公开。 必填项已用*标注