日期：2011-05-02 15:21:00 来源：本站整理
数据库计划指南（二）[MSSQL防范]
本文“数据库计划指南（二）[MSSQL防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
第2 部份— 计划表和字段
1. 查抄各种改变
我在计划数据库的时刻会考虑到哪些数据字段将来大概会发生变更.比方说,姓氏就是如此（注意是西方人的姓氏,比方女性成婚后从夫姓等）.所以,在成立系统存储客户信息时,我偏向于在单独的一个数据表里存储姓氏字段,并且还附加起始日和终止日等字段,这样便可以跟踪这一数据条目的改变.
2. 采取有意义的字段名
有一回我参与开辟过一个项目,此中有从其他程序员那边担当的程序,那个程序员喜好用屏幕上显示数据指导用语命名字段,这也不赖,但不幸的是,她还喜好用一些奇特的命名法,其命名采取了匈牙利命名和掌握序号的组合情势,比方cbo1、txt2、txt2_b 等等.
除非你在利用只面向你的缩写字段名的系统,不然请尽大概地把字段描写的清楚些.当然,也别做过头了,比方Customer_Shipping_Address_Street_Line_1 I 固然很富有阐明性,但没人乐意键入这么长的名字,具体尺度就在你的掌控中.
3. 采取前缀命名
假如多个表里有好多同一范例的字段（比方FirstName）,你无妨用特定表的前缀（比方CusLastName）来帮忙你标识字段.
时效性数据应包含"近来更新日期/时间"字段.时间标志对查找数据问题的缘由、按日期重新处理/重载数据和排除旧数据分外有效.
5. 尺度化和数据驱动
数据的尺度化不但便利了自己并且也便利了其他人.比方说,假定你的用户界面要拜候外部数据源（文件、XML 文档、其他数据库等）,你无妨把呼应的衔接和途径信息存储在用户界面支持表里.还有,假如用户界面履行工作流之类的任务（发送邮件、打印信笺、改正记录状况等）,那么产生工作流的数据也可以存放在数据库里.预先安置总需求付出勤奋,但假如这些历程采取数据驱动而非硬编码的方法,那么战略变更和保护城市便利得多.事实上,假如历程是数据驱动的,你便可以把相当大的责任推给用户,由用户来保护自己的工作流历程.
6. 尺度化不能过头
对那些不熟习尺度化一词（normalization ）的人而言,尺度化可以保证表内的字段都是最底子的要素,而这一办法有助于消除数据库中的数据冗余.尺度化有好几种情势,但Third Normal Form（3NF）普通被认为在性能、扩大性和数据完好性方面到达了最好均衡.简单来说,3NF 规定:
· 表内的每一个值都只能被表达一次.
· 表内的每一行都应当被唯一的标识（有唯一键）.
· 表内不该该存储依靠于其他键的非键信息.
服从3NF 尺度的数据库具有以下特点:有一组表专门存放通过键衔接起来的关联数据.比方说,某个存放客户及其有关订单的3NF 数据库便大概有两个表:Customer 和Order.Order 表不包含订单关联客户的任何信息,但表内会存放一个键值,该键指向Customer 表里包含该客户信息的那一行.
更高层次的尺度化也有,但更尺度能否就一定更好呢?答案是不一定.事实上,对某些项目来说,乃至就连3NF 都大概给数据库引入太高的复杂性.
为了效率的来由,对表不举行尺度化有时也是必要的,这样的例子很多.曾经有个开辟达政解析软件的活就是用非尺度化表把查询时间从平均40 秒降低到了两秒左右.固然我不得不这么做,但我毫不把数据表的非尺度化当作当然的计划理念.而具体的操作不过是一种派生.所以假如表出了问题重新产生非尺度化的表是完好大概的.
7. Microsoft Access 报表本领
假如你正在利用Microsoft Access,你可以用对用户友好的字段名来替换编号的名称:比方用Customer Name 替换txtCNaM.这样,当你用向导程序成立表单和报表时,其名字会让那些不是程序员的人更简单阅读.
8. 不活泼大概不采取的指导符
增添一个字段表示所在记录能否在业务中不再活泼挺有效的.不管是客户、员工还是其他什么人,这样做都能有助于再运行查询的时刻过滤活泼大概不活泼状况.同时还消除了新用户在采取数据时所面对的一些问题,比方,某些记录大概不再为他们所用,再删除的时刻可以起到一定的防备作用.
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 等.
采取普通抽象术语来标识"事物"的类别可以让你在关联数据以满意业务要求方面得到宏大的机动性,同时这样做还可以明显降低数据存储所需的冗余量.
11. 用户来自世界各地
在计划用到网络大概具有其他国际特点的数据库时,一定要记着大大都国家都有差别的字段格局,比方邮政编码等,有些国家,比方新西兰就没有邮政编码一说.
12. 数据反复需求采取分立的数据表
假如你发现自己在反复输入数据,请成立新表和新的关系.
13. 每个表中都应当增添的3 个有效的字段
· dRecordCreationDate,在VB 下默许是Now(),而在sql server 下默许为GETDATE()
· sRecordCreator,在SQL Server 下默许为NOT NULL DEFAULT USER
· nRecordVersion,记录的版本标志;有助于精确阐明记录中呈现null 数据大概丧失数据的缘由.
14. 对地址和电话采取多个字段
描写街道地址就短短一行记录是不够的.Address_Line1、Address_Line2 和Address_Line3 可以供应更大的机动性.还有,电话号码和邮件地址最好拥有自己的数据表,其间具有自身的范例和标志类别.
过度尺度化可要当心,这样做大概会招致性能上呈现问题.固然地址和电话表别离普通可以到达最佳状况,但是假如需求常常拜候这类信息,大概在其父表中存放"首选"信息（比方Customer 等）更为妥当些.非尺度化和加快拜候之间的让步是有一定意义的.
15. 利用多个名称字段
我认为很吃惊,很多人在数据库里就给name 留一个字段.我认为只有刚入门的开辟人员才会这么做,但实际上网上这种做法非常广泛.我倡议应当把姓氏和名字当作两个字段来处理,然后在查询的时刻再把他们组合起来.
要把这种情形变得对用户更为友好有好些办法.我最常用的是在同一表中成立一个计算列,通过它可以自动地衔接尺度化后的字段,这样数据变更的时刻它也随着变.不过,这样做在采取建模软件时得很机警才行.总之,采取衔接字段的方法可以有效的断绝用户利用和开辟人员界面.
16. 防备大小写混用的对象名和特别字符
过去最令我恼火的事情之一就是数据库里有大小写混用的对象名,比方CustomerData.这一问题从Access 到Oracle 数据库都存在.我不喜好采取这种大小写混用的对象命名办法,后果还不得不手工改正名字.想想看,这种数据库/利用程序能混到采取更强盛数据库的那一天吗?采取全部大写并且包含下划符的名字具有更好的可读性（CUSTOMER_DATA）,绝对不要在对象名的字符之间留空格.
17. 当心保存词
要保证你的字段名没有和保存词、数据库系统大概常用拜候办法冲突,比方,近来我编写的一个ODBC 衔接程序里有个表,此中就用了DESC 作为阐明字段名.后果不可思议!DESC 是DESCENDING 缩写后的保存词.表里的一个SELECT *语句倒是能用,但我得到的倒是一大堆毫无用处的信息.
18. 保持字段名和范例的一致性
在命名字段并为其指定数据范例的时刻一定要保证一致性.假定字段在某个表中叫做"agreement_number",你就别在另一个表里把名字改成"ref1".假定数据范例在一个表里是整数,那在另一个表里可就别变成字符型了.记着,你干完自己的活了,其他人还要用你的数据库呢.
19. 细心挑选数字范例
在SQL 中利用smallint 和tinyint 范例要分外当心,比方,假定你想看看月贩卖总额,你的总额字段范例是smallint,那么,假如总额超越了$32,767 你就不能举行计算操作了.
20. 删除标志
在表中包含一个"删除标志"字段,这样便可以把行标志为删除.在关系数据库里不要单独删除某一行;最好采取排除数据程序并且要细心保护索引整体性
以上是“数据库计划指南（二）[MSSQL防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
- ·上一篇文章：SQL数据操作底子(中级)8
- ·下一篇文章：数据库计划指南（一）
- ·
中查找“数据库计划指南（二）”更多相关内容 - ·
中查找“数据库计划指南（二）”更多相关内容
评论内容只代表网友观点，与本站立场无关！
评论摘要(共 0 条，得分 0 分，平均 0 分)
查看完整评论