数据库设计心得

《数据库设计心得》由会员分享，可在线阅读，更多相关《数据库设计心得（10页珍藏版）》请在金锄头文库上搜索。

1、数据库设计阅历谈数据库设计阅历谈一个成功的治理系统，是由：50% 的业务 + 50% 的软件 所组成，而 50% 的成功软件又有 25% 的数据库 + 25% 的程序 所组成，数据库设计的好坏是一个关键。假设把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一局部。有关数据库设计的材料汗牛充栋，高校学位课程里也有特地的表达。不过，就如我们反复强调的那样，再好的教师也比不过阅历的教导。所以我归纳历年来所走的弯路及体会，并在网上找了些对数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和阅历。精选了其中的 60 个最正确技巧，并把这些技巧编写成了本文，为了便利索引其内容划

2、分为 5 个局部：第 1 局部 - 设计数据库之前这一局部排列了 12 个根本技巧，包括命名标准和明确业务需求等。第 2 局部 - 设计数据库表总共 24 个指南性技巧，涵盖表内字段设计以及应当避开的常见问题等。第 3 局部 - 选择键怎么选择键呢？这里有 10 个技巧特地涉及系统生成的主键的正确用法，还有何 时以及如何索引字段以获得最正确性能等。第 4 局部 - 保证数据完整性争辩如何保持数据库的清楚和强健，如何把有害数据降低到最小程度。第 5 局部 - 各种小技巧不包括在以上 4 个局部中的其他技巧，五花八门，有了它们期望你的数据库开发工作会更轻松一些。第 1 局部 - 设计数据库之前考察

3、现有环境在设计一个新数据库时，你不但应当认真争辩业务需求而且还要考察现有的系统。大多数数据库工程都不是从头开头建立的；通常，机构内总会存在用来满足特定需求的现有系统可 能没有实现自动计算。明显，现有系统并不完善，否那么你就不必再建立新系统了。但是对旧系统的争辩可以让你觉察一些可能会无视的微小问题。一般来说，考察现有系统对你确定有好处。定义标准的对象命名标准肯定要定义数据库对象的命名标准。对数据库表来说，从工程一开头就要确定表名是承受复数还是单数形式。此外还要给表的别名定义简洁规章比方说，假设表名是一个单词，别名就取单词的前 4 个字母；假设表名是两个单词，就各取两个单词的前两个字母组成 4 个

4、字母长的别名；假设表的名字由 3 个单词组成，你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成 4 字母长的别名，其余依次类推对工作用表来说，表名可以加上前缀 WORK_ 后面附上承受该表的应用程序的名字。表内的列字段要针对键承受一整套设计规章。比方，假设键是数字类型，你可以用_N 作为后缀；假设是字符类型那么可以承受 _C 后缀。对列字段名应当承受标准的前缀和后缀。再如，假设你的表里有好多“money”字段，你不妨给每个列字段增加一个 _M 后缀。还有，日期列字段最好以 D_ 作为名字打头。检查表名、报表名和查询名之间的命名标准。你可能会很快就被这些不同的数据库要

5、素的名称搞糊涂了。假设你坚持统一地命名这些数据库的不同组成局部，至少你应当在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区分。假设承受了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象比方 tbl_Employees。我在和 SQL Server 打交道的时候还用过 tbl 来索引表，但我用 sp_company 现在用 sp_feft_标识存储过程，由于在有的时候假设我觉察了更好的处理方法往往会保存好几个拷贝。我在实现 SQL Server 2000 时用 udf_ 或者类似的标记标识我编写的函数。工欲善其事,

6、 必先利其器承受抱负的数据库设计工具，比方：SyBase 公司的 PowerDesign，她支持 PB、VB、Delphe 等语言，通过 ODBC 可以连接市面上流行的 30 多个数据库，包括 dBase、FoxPro、VFP、SQL Server 等，今后有时机我将着重介绍 PowerDesign 的使用。猎取数据模式资源手册正在寻求例如模式的人可以阅读数据模式资源手册一书，该书由 Len Silverston、W.H. Inmon 和 Kent Graziano 编写，是一本值得拥有的最正确数据建模图书。该书包括的章节涵盖多种数据领域，比方人员、机构和工作效能等。其他的你还可以参考：1萨师

7、煊王珊著 数据库系统概论(其次版)高等训练出版社 1991、2美 Steven M.Bobrowski 著 Oracle 7 与客户效劳器计算技术从入门到精通 刘建元等译 电子工业出版社，1996、3周中元 信息系统建模方法(下) 电子与信息化 1999 年第 3 期，1999畅想将来，但不行忘了过去的教训我觉察询问用户如何对待将来需求变化格外有用。这样做可以到达两个目的：首先，你可以清楚地了解应用设计在哪个地方应当更具机敏性以及如何避开性能瓶颈；其次，你知道发生事先没有确定的需求变更时用户将和你一样感到吃惊。肯定要记住过去的阅历教训！我们开发人员还应当通过共享自己的体会和阅历相互挂念。即使用

8、户认为他们再也不需要什么支持了，我们也应当对他们进展这方面的训练，我们都曾经面临过这样的时刻“当时要是这么做了该多好.”。在物理实践之前进展规律设计在深化物理设计之前要先进展规律设计。随着大量的 CASE 工具不断涌现出来，你的设计也可以到达相当高的规律水准，你通常可以从整体上更好地了解数据库设计所需要的方方面面。了解你的业务在你百分百地确定系统从客户角度满足其需求之前不要在你的 ER实体关系模式中参加哪怕一个数据表怎么，你还没有模式？那请你参看技巧 9。了解你的企业业务可以在以后的开发阶段节约大量的时间。一旦你明确了业务需求，你就可以自己做出很多决策了。一旦你认为你已经明确了业务内容，你最好

9、同客户进展一次系统的沟通。承受客户的术语并且向他们解释你所想到的和你所听到的。同时还应当用可能、将会和必需等词汇表达出系统的关系基数。这样你就可以让你的客户订正你自己的理解然后做好下一步的 ER 设计。创立数据字典和 ER 图表肯定要花点时间创立 ER 图表和数据字典。其中至少应当包含每个字段的数据类型和在每个表内的主外键。创立 ER 图表和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。越早创立越能有助于避开今后面临的可能混乱，从而可以让任何了解数据库的人都明确如何从数据库中获得数据。有一份诸如 ER 图表等最新文档其重要性如何强调都不过分，这对说明表之间关系很有用， 而数

10、据字典那么说明白每个字段的用途以及任何可能存在的别名。对 SQL 表达式的文档化来说这是完全必要的。创立模式一张图表赛过千言万语：开发人员不仅要阅读和实现它，而且还要用它来挂念自己和用户对话。模式有助于提高协作效能，这样在先期的数据库设计中几乎不行能消灭大的问题。模式不必弄的很简单；甚至可以简洁到手写在一张纸上就可以了。只是要保证其上的规律关系今后能产生效益。从输入输出下手在定义数据库表和字段需求输入时，首先应检查现有的或者已经设计出的报表、查询和视图输出以打算为了支持这些输出哪些是必要的表和字段。举个简洁的例子：假设客户需要一个报表依据邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编

11、码字段而不要把邮政编码糅进地址字段里。报表技巧要了解用户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每月、每个季度还是每年？假设需要的话还可以考虑创立总结表。系统生成的主键在报表中很难治理。用户在具有系统生成主键的表内用副键进展检索往往会返回很多重复数据。这样的检干脆能比较低而且简洁引起混乱。理解客户需求看起来这应当是显而易见的事，但需求就是来自客户这里要从内部和外部客户的角度考 虑。不要依靠用户写下来的需求，真正的需求在客户的脑袋里。你要让客户解释其需求， 而且随着开发的连续，还要经常询问客户保证其需求仍旧在开发的目的之中。一个不变的真 理是：“只有我观察了我才知道我

12、想要的是什么”必定会导致大量的返工，由于数据库没有到达客户从来没有写下来的需求标准。而更糟的是你对他们需求的解释只属于你自己，而且可 能是完全错误的。第 2 局部 - 设计表和字段检查各种变化我在设计数据库的时候会考虑到哪些数据字段将来可能会发生变更。比方说，姓氏就是如此留意是西方人的姓氏，比方女性结婚后从夫姓等。所以，在建立系统存储客户信息时， 我倾向于在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。承受有意义的字段名有一回我参与开发过一个工程，其中有从其他程序员那里继承的程序，那个程序员宠爱用屏 幕上显示数据指示用语命名字段，这也不赖，但

13、不幸的是，她还宠爱用一些惊异的命名法， 其命名承受了匈牙利命名和把握序号的组合形式，比方 cbo1、txt2、txt2_b 等等。除非你在使用只面对你的缩写字段名的系统，否那么请尽可能地把字段描述的清楚些。固然， 也别做过头了，比方 Customer_Shipping_Address_Street_Line_1，虽然很富有说明性，但没人情愿键入这么长的名字，具体尺度就在你的把握中。承受前缀命名假设多个表里有好多同一类型的字段比方 FirstName，你不妨用特定表的前缀比方 CusLastName来挂念你标识字段。时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的缘由、按日期

14、重新处理/重载数据和去除旧数据特别有用。标准化和数据驱动数据的标准化不仅便利了自己而且也便利了其他人。比方说，假设你的用户界面要访问外部 数据源文件、XML 文档、其他数据库等，你不妨把相应的连接和路径信息存储在用户界面支持表里。还有，假设用户界面执行工作流之类的任务发送邮件、打印信笺、修改记录状态等，那么产生工作流的数据也可以存放在数据库里。预先支配总需要付出努力，但假设这些过程承受数据驱动而非硬编码的方式，那么策略变更和维护都会便利得多。事实上， 假设过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过 程。标准化不能过头对那些不生疏标准化一词normalizati

15、on的人而言，标准化可以保证表内的字段都是最根底的要素，而这一措施有助于消退数据库中的数据冗余。标准化有好几种形式，但 Third Normal Form3NF通常被认为在性能、扩展性和数据完整性方面到达了最好平衡。简单来说，3NF 规定：* 表内的每一个值都只能被表达一次。* 表内的每一行都应当被唯一的标识有唯一键。* 表内不应当存储依靠于其他键的非键信息。遵守 3NF 标准的数据库具有以下特点：有一组表特地存放通过键连接起来的关联数据。比方说，某个存放客户及其有关定单的 3NF 数据库就可能有两个表：Customer 和 Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向 Customer表里包含该客户信息的那一行。更高层次的标准化也有，但更标准是否就肯定更好呢？答案是不肯定。事实上，对某些工程来说，甚至就连 3NF 都可能给数据库引入太高的简单性。为了效率的原因，对表不进展标准化有时也是必要的，这样的例子很多。曾经有个开发餐饮分析软件的活就是用非标准化表把查询时间从平均 40 秒降低到了两秒左右。虽然我不得不这么做，但我绝不把数据表的非标准化当作固然的设计理念。而具体的操作不过是一种派生。所以假设表出了问题重新产生非标准化的表是完全可能的。Microsoft Visual FoxPro 报表技巧假设你正在