日期：2011-05-02 15:21:00 来源：本站整理
数据库计划指南（一）[MSSQL防范]
本文“数据库计划指南（一）[MSSQL防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
假如把企业的数据比做生命所必须的血液,那么数据库的计划就是利用中最重要的一部份.有关数据库计划的质料汗牛充栋,大学学位课程里也有专门的报告.不过,就如我们反复夸大的那样,再好的老师也比不过经验的教导.所以我近来找了些对数据库计划颇有成就的专业人士给大家传授一些计划数据库的本领和经验.我从收到的130 个反馈中精选了此中的60 个最佳本领,并把这些本领编写成了本文,为了便利索引其内容划分为5 个部份:
第1 部份— 计划数据库之前
1. 观察现有环境
在计划一个新数据库时,你不但应当细心研究业务需求并且还要观察现有的系统.大大都数据库项目都不是重新开始成立的;普通,机构内总会存在用来满意特定需求的现有系统（大概没有实现自动计算）.明显,现有系统并不完善,不然你就没必要再成立新系统了.但是对旧系统的研究可以让你发现一些大概会忽视的渺小问题.普通来说,观察现有系统对你绝对有好处.
我曾经接办过一个为区域运输公司开辟的数据库项目,活不难,用的是Access 数据库.我设置了一些项目计划参数,并且同客户一道对这些参数举行了评价,事前还查看了开辟环境下所采纳的工作情势,等到最后布置利用的时刻,只见终端上出了几个提醒符然后立马在我眼前翘辫子了!抓耳挠腮的折腾了好几个小时,我才意识到,本来这家公司的网络上跑着两个数据库利用,而对网络的拜候需求明确和严峻的用户帐号及其拜候权限.懂得了这一点,问题迎刃而解:只需采取客户的系统便可.这个项目给我的教导就是:记着,假定你在诸如Access 大概Interbase 这类大众环境下开辟利用程序,一定要从表面下手深化系统内部搞清楚你面对的环境毕竟是怎么回事.
2. 定义尺度的对象命名标准
一定要定义数据库对象的命名标准.对数据库表来说,从项目一开始就要肯定表名是采取复数还是单数情势.此外还要给表的别名定义简单法则（比方说,假如表名是一个单词,别名就取单词的前4 个字母;假如表名是两个单词,就各取两个单词的前两个字母构成4 个字母长的别名;假如表的名字由3 个单词构成,你无妨重新两个单词中各取一个然后从最后一个单词中再取出两个字母,后果还是构成4 字母长的别名,别的顺次类推）对工作用表来说,表名可以加上前缀WORK_ 背面附上采取该表的利用程序的名字.表内的列要针对键采取一整套计划法则.比方,假如键是数字范例,你可以用_NO 作为后缀;假如是字符范例则可以采取_CODE 后缀.对列名应当采取尺度的前缀和后缀.再如,假定你的表里有好多"money"字段,你无妨给每个列增添一个_AMT 后缀.还有,日期列最好以DATE_作为名字打头.
查抄表名、报表名和查询名之间的命名标准.你大概会很快就被这些差别的数据库要素的名称搞胡涂了.假定你保持统一地命名这些数据库的差别构成部份,至少你应当在这些对象名字的开首用table、query 大概report 等前缀加以辨别.
假如采取了Microsoft Access,你可以用qry、rpt、tbl 和mod 等标记来标识对象（比方
tbl_Employees）.我在和sql server（大概Oracle）打交道的时刻还用过tbl 来索引表,但我用sp_company （目前用sp_feft_）标识存储历程,因为在有的时刻假如我发现了更好的处理办法常常会保存好几个拷贝.我在实现SQL Server 2000 时用udf_ （大概近似的标志）标识我编写的函数.
3. 预先筹划
上个世纪80 年代初,我还在利用资产帐目系统和System 38 平台,当时我负责计划全部的日期字段,这样在不费什么力气的情形下将来便可以轻松处理2000 年问题了.很多人给我说就别去办理这一问题了,因为要处理起来太麻烦了（这在众人皆知的Y2K 问题之前好久了）.我反击说只要预先筹划此后就不会碰到大麻烦.后果我只用了两周的时间就把程序全部改完了.因为预先筹划的好,后来Y2K 问题对该系统的危害降到了最低程度（近来据说该程序乃至到了1995 年都还运行在AS/400 系统上,唯一呈现的小问题是从代码中删除注释费了点时间）.
4. 获得数据情势资源手册
正在追求示例情势的人可以阅读《数据情势资源手册》一书,该书由Len Silverston、W. H.Inmon 和Kent Graziano 编写,是一本值得拥有的最佳数据建模图书.该书包含的章节涵盖多种数据范畴,比方人员、机构和工作效能等.
5. 畅想将来,但不可忘了过去的教导
我发现询问用户若何对待将来需求改变非常有效.这样做可以到达两个目的:首先,你可以清楚地理解利用计划在哪个地方应当更具机动性以及若何避免性能瓶颈;其次,你知道发闹事前没有肯定的需求变更时用户将和你一样感到吃惊.
一定要记着过去的经验教导!我们开辟人员还应当通过度享自己的领会和经验彼此帮忙.即便用户认为他们再也不需求什么支持了,我们也应当对他们举行这方面的教诲,我们都曾经面对过这样的时刻"当初如果这么做了该多好;".
6. 在物理实践之前举行逻辑计划
在深化物理计划之前要先举行逻辑计划.随着大量的CASE 工具不断涌现出来,你的计划也可以到达相当高的逻辑水准,你普通可以从整体上更好地理解数据库计划所需求的各个方面.
7. 理解你的业务
在你百分百地肯定系统从客户角度满意其需求之前不要在你的ER（实体关系）情势中加入哪怕一个数据表（怎么,你还没有情势?那请你参看本领9）.理解你的企业业务可以在今后的开辟阶段节俭大量的时间.一旦你明确了业务需求,你便可以自己做出很多抉择了.
一旦你认为你已经明确了业务内容,你最好同客户举行一次系统的交流.采取客户的术语并且向他们注释你所想到的和你所听到的.同时还应当用大概、将会和必须等词汇表达出系统的关系基数.这样你便可以让你的客户改正你自己的理解然后做好下一步的ER 计划.
8. 成立数据字典和ER 图表
一定要花点时间成立ER 图表和数据字典.此中至少应当包含每个字段的数据范例和在每个表内的主外键.成立ER 图表和数据字典确切有点费时但对其他开辟人员要理解整个计划倒是完好必要的.越早成立越能有助于避免今背面对的大概混乱,从而可以让任何理解数据库的人都明确若何从数据库中得到数据.
有一份诸如ER 图表等最新文档其重要性若何夸大都不过度,这对表明表之间关系很有效,而数据字典则阐明了每个字段的用处以及任何大概存在的别名.对SQL 表达式的文档化来说这是完好必要的.
9. 成立情势
一张图表赛过千言万语:开辟人员不但要阅读和实现它,并且还要用它来帮忙自己和用户对话.情势有助于提高合作效能,这样在先期的数据库计划中几近不大概呈现大的问题.情势没必要弄的很复杂;乃至可以简单到手写在一张纸上便可以了.只是要保证其上的逻辑关系此后能产见效益.
10. 从输入输出下手
在定义数据库表和字段需求（输入）时,首先应查抄现有的大概已经计划出的报表、查询和视图（输出）以决意为了支持这些输出哪些是必要的表和字段.举个简单的例子:假定客户需求一个报表按照邮政编码排序、分段和求和,你要保证此中包含了单独的邮政编码字段而不要把邮政编码糅进地址字段里.
11. 报表本领
要理解用户普通是若何报告数据的:批处理还是在线提交报表?时间隔断是每天、每周、每月、每个季度还是每年?假如需求的话还可以考虑成立总结表.系统生成的主键在报表中很难管理.用户在具有系统生成主键的表内用副键举行检索常常会返回很多反复数据.这样的检干脆能对比低并且简单惹起混乱.
12. 理解客户需求
看起来这应当是显而易见的事,但需求就是来自客户（这里要从内部和外部客户的角度考虑）.不要依靠用户写下来的需求,真正的需求在客户的脑袋里.你要让客户注释其需求,并且随着开辟的持续,还要常常询问客户保证其需求仍旧在开辟的目的之中.一个不变的真理是:"只有我瞥见了我才知道我想要的是什么"必定会招致大量的返工,因为数据库没有到达客户历来没有写下来的需求尺度.而更糟的是你对他们需求的注释只属于你自己,并且大概是完好错误的
以上是“数据库计划指南（一）[MSSQL防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
中查找“数据库计划指南（一）”更多相关内容
中查找“数据库计划指南（一）”更多相关内容评论内容只代表网友观点，与本站立场无关！
评论摘要(共 0 条，得分 0 分，平均 0 分)
查看完整评论