个成功管理系统是由:[50% 业务 + 50% 软件Software] 所组成而 50% 成功软件Software又有 [25% 数据库 + 25% ] 所组成数据库设计好坏是个关键如果把企业数据比做生命所必需血液那么数据库设计就是应用中最重要部分有关数据库设计材料汗牛充栋大学学位课程里也有专门讲述不过就如我们反复强调那样再好老师也比不过经验教诲所以我归纳历年来所走弯路及体会并在网上找了些对数据库设计颇有造诣专业人士给大家传授些设计数据库窍门技巧和经验精选了其中 60 个最佳窍门技巧并把这些窍门技巧编写成了本文为了方便索引其内容划分为 5 个部分:
第 1 部分 - 设计数据库的前
这部分罗列了 12 个基本窍门技巧包括命名规范标准和明确业务需求等
第 2 部分 - 设计数据库表
总共 24 个指南性窍门技巧涵盖表内字段设计以及应该避免常见问题等
第 3 部分 - 选择键
如何选择键呢？这里有 10 个窍门技巧专门涉及系统生成主键正确使用方法还有何 时以及如何索引字段以获得最佳性能等
第 4 部分 - 保证数据完整性
讨论如何保持数据库清晰和健壮如何把有害数据降低到最小程度
第 5 部分 - 各种小窍门技巧
不包括在以上 4 个部分中其他窍门技巧 5花 8门有了它们希望你数据库开发工作会更轻松些
第 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]萨师煊　王珊著　数据库系统概论(第 2版)高等教育出版社 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 Normal Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡简单来说3NF 规定:
* 表内每个值都只能被表达次
* 表内每行都应该被唯标识(有唯键)
* 表内不应该存储依赖于其他键非键信息
遵守 3NF 标准数据库具有以下特点:有组表专门存放通过键连接起来关联数据比方说某个存放客户及其有关定单 3NF 数据库就可能有两个表:Customer 和 OrderOrder 表不包含定单关联客户任何信息但表内会存放个键值该键指向 Customer 表里包含该客户信息那行
更高层次标准化也有但更标准是否就定更好呢？答案是不定事实上对某些项目来说甚至就连 3NF 都可能给数据库引入太高复杂性
为了效率缘故对表不进行标准化有时也是必要这样例子很多曾经有个开发餐饮分析软件Software活就是用非标准化表把查询时间从平均 40 秒降低到了两秒左右虽然我不得不这么做但我绝不把数据表非标准化当作当然设计理念而具体操作不过是种派生所以如果表出了问题重新产生非标准化表是完全可能
Microsoft Visual FoxPro 报表窍门技巧
如果你正在使用 Microsoft Visual FoxPro你可以用对用户友好字段名来代替编号名称:比如用 Customer Name 代替 txtCNaM这样当你用向导 [Wizards台湾人称为‘精灵'] 创建表单和报表时其名字会让那些不是员人更容易阅读
不活跃或者不采用指示符
增加个字段表示所在记录是否在业务中不再活跃挺有用不管是客户、员工还是其他什么人这样做都能有助于再运行查询时候过滤活跃或者不活跃状态同时还消除了新用户在采用数据时所面临些问题比如某些记录可能不再为他们所用再删除时候可以起到定防范作用
使用角色实体定义属于某类别列[字段]
在需要对属于特定类别或者具有特定角色事物做定义时可以用角色实体来创建特定时间关联关系从而可以实现自我文档化
这里含义不是让 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 记录来反映新头衔变化不过这样来在时间上无法跟踪个人所处位置具体时间
采用常用实体命名机构数据
组织数据最简单办法就是采用常用名字比如: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 等
采用般抽象术语来标识“事物”类别可以让你在关联数据以满足业务要求方面获得巨大灵活性同时这样做还可以显著降低数据存储所需冗余量
用户来自世界各地
在设计用到网络或者具有其他国际特性数据库时定要记住大多数国家都有区别字段格式比如邮政编码等有些国家比如新西兰就没有邮政编码说
数据重复需要采用分立数据表
如果你发现自己在重复输入数据请创建新表和新关系
每个表中都应该添加 3 个有用字段
* dRecordCreationDate在 VB 下默认是 Now而在 SQL Server 下默认为 GETDATE
* sRecordCreator在 SQL Server 下默认为 NOT NULL DEFAULT USER
* nRecordVersion记录版本标记；有助于准确介绍说明记录中出现 null 数据或者丢失数据原因
对地址和电话采用多个字段
描述街道地址就短短行记录是不够Address_Line1、Address_Line2 和 Address_Line3 可以提供更大灵活性还有电话号码和邮件地址最好拥有自己数据表其间具有自身类型和标记类别
过分标准化可要小心这样做可能会导致性能上出现问题虽然地址和电话表分离通常可以达到最佳状态但是如果需要经常访问这类信息或许在其父表中存放“首选”信息(比如 Customer 等)更为妥当些非标准化和加速访问的间妥协是有定意义
使用多个名称字段
我觉得很吃惊许多人在数据库里就给 name 留个字段我觉得只有刚入门开发人员才会这么做但实际上网上这种做法非常普遍我建议应该把姓氏和名字当作两个字段来处理然后在查询时候再把他们组合起来
我最常用是在同表中创建个计算列[字段]通过它可以自动地连接标准化后字段这样数据变动时候它也跟着变不过这样做在采用建模软件Software时得很机灵才行总的采用连接字段方式可以有效隔离用户应用和开发人员界面
提防大小写混用对象名和特殊
过去最令我恼火事情的就是数据库里有大小写混用对象名比如 CustomerData这问题从 Access 到 Oracle 数据库都存在我不喜欢采用这种大小写混用对象命名思路方法结果还不得不手工修改名字想想看这种数据库/应用能混到采用更强大数据库那天吗？采用全部大写而且包含下划符名字具有更好可读性(CUSTOMER_DATA)绝对不要在对象名的间留空格
小心保留词
要保证你字段名没有和保留词、数据库系统或者常用访问思路方法冲突比如最近我编写个 ODBC 连接里有个表其中就用了 DESC 作为介绍说明字段名后果可想而知！DESC 是 DESCENDING 缩写后保留词表里个 SELECT * 语句倒是能用但我得到却是大堆毫无用处信息
保持字段名和类型致性
在命名字段并为其指定数据类型时候定要保证致性假如字段在某个表中叫做“agreement_number”你就别在另个表里把名字改成“ref1”假如数据类型在个表里是整数那在另个表里可就别变成型了记住你干完自己活了其他人还要用你数据库呢
仔细选择数字类型
在 SQL 中使用 small 和 tiny 类型要特别小心比如假如你想看看月销售总额你总额字段类型是 small那么如果总额超过了 $32,767 你就不能进行计算操作了
删除标记
在表中包含个“删除标记”字段这样就可以把行标记为删除在关系数据库里不要单独删除某行；最好采用清除数据而且要仔细维护索引整体性
避免使用触发器
触发器功能通常可以用其他方式实现在调试时触发器可能成为干扰假如你确实需要采用触发器你最好集中对它文档化
包含版本机制
建议你在数据库中引入版本控制机制来确定使用中数据库版本无论如何你都要实现这要求时间长用户需求总是会改变最终可能会要求修改数据库结构虽然你可以通过检查新字段或者索引来确定数据库结构版本但我发现把版本信息直接存放到数据库中不更为方便吗？
给文本字段留足余量
ID 类型文本字段比如客户 ID 或定单号等等都应该设置得比般想象更大时间不长你多半就会要添加额外而难堪不已比方说假设你客户 ID 为 10 位数长那你应该把数据库表字段长度设为 12 或者 13 个长这算浪费空间吗？是有点但也没你想象那么多:个字段加长 3 个在有 1 百万条记录再加上点索引情况下才不过让整个数据库多占据 3MB 空间但这额外占据空间却无需将来重构整个数据库就可以实现数据库规模增长了身份证号码从 15 位变成 18 位就是最好和最惨痛例子
列[字段]命名窍门技巧
我们发现假如你给每个表列[字段]名都采用统前缀那么在编写 SQL 表达式时候会得到大大简化这样做也确实有缺点比如破坏了自动表连接工具作用后者把公共列[字段]名同某些数据库联系起来不过就连这些工具有时不也连接嘛举个简单例子假设有两个表:
Customer 和 OrderCustomer 表前缀是 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 个表乃至更多列[字段]你就知道这个窍门技巧多有用了
第 3 部分 - 选择键和索引
数据采掘要预先计划
我所在某客户部门度要处理 8 万多份联系方式同时填写每个客户必要数据(这绝对不是小活)我从中还要确定出组客户作为市场目标当我从最开始设计表和字段时候我试图不在主索引里增加太多字段以便加快数据库运行速度然后我意识到特定组查询和信息采掘既不准确速度也不快结果只好在主索引中重建而且合并了数据字段我发现有个指示计划相当关键——当我想创建系统类型查找时为什么要采用号码作为主索引字段呢？我可以用传真号码进行检索但是它几乎就象系统类型样对我来说并不重要采用后者作为主字段数据库更新后重新索引和检索就快多了
可操作数据仓库(ODS)和数据仓库(DW)这两种环境下数据索引是有差别在 DW 环境下你要考虑销售部门是如何组织销售活动他们并不是数据库管理员但是他们确定表内键信息这里设计人员或者数据库工作人员应该分析数据库结构从而确定出性能和正确输出的间最佳条件
使用系统生成主键
这类同窍门技巧 1但我觉得有必要在这里重复提醒大家假如你总是在设计数据库时候采用系统生成键作为主键那么你实际控制了数据库索引完整性这样数据库和非人工机制就有效地控制了对存储数据中每行访问
采用系统生成键作为主键还有个优点:当你拥有致键结构时找到逻辑缺陷很容易
分解字段用于索引
为了分离命名字段和包含字段以支持用户定义报表请考虑分解其他字段(甚至主键)为其组成要素以便用户可以对其进行索引索引将加快 SQL 和报表生成器脚本执行速度比方说我通常在必须使用 SQL LIKE 表达式情况下创建报表 number 字段无法分解为 year、serial number、 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 部分 - 各种小窍门技巧
文档、文档、文档
对所有快捷方式、命名规范标准、限制和都要编制文档
采用给表、列[字段]、触发器等加注释数据库工具是这有点费事但从长远来看这样做对开发、支持和跟踪修改非常有用
取决于你使用数据库系统可能有些软件Software会给你些供你很快上手文档你可能希望先开始在说然后获得越来越多细节或者你可能希望周期性预排在输入新数据同时随着你进展对每部分细节化不管你选择哪种方式总要对你数据库文档化或者在数据库自身内部或者单独建立文档这样当你过了年多时间后再回过头来做第 2 个版本你犯错机会将大大减少
使用常用英语(或者其他任何语言)而不要使用编码
为什么我们经常采用编码(比如 9935A 可能是‘青岛啤酒'供应代码4XF788-Q 可能是帐目编码)？理由很多但是用户通常都用英语进行研究而不是编码工作 5 年会计或许知道 4XF788-Q 是什么东西但新来可就不定了在创建下拉菜单、列表、报表时最好按照英语名排序假如你需要编码那你可以在编码旁附上用户知道英语
保存常用信息
让个表专门存放般数据库信息非常有用我常在这个表里存放数据库当前版本、最近检查/修复(对 FoxPro)、关联设计文档名称、客户等信息这样可以实现种简单机制跟踪数据库当客户抱怨他们数据库没有达到希望要求而和你联系时这样做对非客户机/服务器环境特别有用
测试、测试、反复测试
建立或者修订数据库的后必须用用户新输入数据测试数据字段最重要是让用户进行测试并且同用户道保证你选择数据类型满足商业要求测试需要在把新数据库投入实际服务的前完成
检查设计
在开发期间检查数据库设计常用技术是通过其所支持应用原型检查数据库换句话说针对每种最终表达数据原型应用保证你检查了数据模型并且查看如何取出数据
Microsoft Visual FoxPro 设计窍门技巧
对复杂 Microsoft Visual FoxPro 数据库应用而言可以把所有主表放在个数据库容器文件里然后增加其他数据库表文件和装载同原有数据库有关特殊文件根据需要用这些文件连接到主文件中主表比如数据输入、数据索引、统计分析、向管理层或者政府部门提供报表以及各类只读查询等这措施简化了用户和组权限分配而且有利于应用(存储过程)分组和划分从而在必须修改时候易于管理