日期：2011-05-02 15:22:00 来源：本站整理
数据库计划指南（三）[MSSQL防范]
本文“数据库计划指南（三）[MSSQL防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
21. 避免利用触发器
触发器的功效普通可以用其他方法实现.在调试程序时触发器大概成为干扰.假定你确切需求采取触发器,你最好集合对它文档化.
22. 包含版本机制
倡议你在数据库中引入版本掌握机制来肯定利用中的数据库的版本.无论若何你都要实现这一要求.时间一长,用户的需求老是会改变的.终究大概会要求改正数据库构造.固然你可以通过查抄新字段大概索引来肯定数据库构造的版本,但我发现把版本信息直接存放到数据库中不更为便利吗?.
23. 给文本字段留足余量
ID 范例的文本字段,比方客户ID 或订单号等等都应当设置得比普通想象更大,因为时间不长你大都就会因为要增添额外的字符而尴尬不已.比方说,假定你的客户ID 为10 位数长.那你应当把数据库表字段的长度设为12 大概13 个字符长.这算浪费空间吗?是有一点,但也没你想象的那么多:一个字段加长3 个字符在有1 百万条记录,再加上一点索引的情形下才不过让整个数据库多占据3MB 的空间.但这额外占据的空间却无需将来重构整个数据库便可以实现数据库规模的增长了.
24. 列命名本领
我们发现,假定你给每个表的列名都采取统一的前缀,那么在编写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_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 部份— 挑选键和索引
1. 数据采掘要预先筹划
我所在的市场部门一度要处理8 万多份接洽方法,同时填写每个客户的必要数据（这绝对不是小活）.我从中还要肯定出一组客户作为市场目标.当我从最开始计划表和字段的时刻,我试图不在主索引里增添太多的字段以便加快数据库的运行速度.然后我意识到特定的组查询和信息采掘既不精确速度也不快.后果只好在主索引中重建并且归并了数据字段.我发现有一个指导筹划相当关键——当我想成立系统范例查找时为什么要采取号码作为主索引字段呢?我可以用传真号码举行检索,但是它几近就象系统范例一样对我来说并不重要.采取后者作为主字段,数据库更新后重新索引和检索就快多了.
可操作数据仓库（ODS）和数据仓库（DW）这两种环境下的数据索引是有差别的.在DW 环境下,你要考虑贩卖部门是若何组织贩卖活动的.他们并非数据库管理员,但是他们肯定表内的键信息.这里计划人员大概数据库工作人员应当解析数据库构造从而肯定出性能和精确输出之间的最佳条件.
2. 利用系统生成的主键
这一天类同本领1,但我认为有必要在这里反复提醒大家.假定你老是在计划数据库的时刻采取系统生成的键作为主键,那么你实际掌握了数据库的索引完好性.这样,数据库和非人工机制就有效地掌握了对存储数据中每一行的拜候.
采取系统生成键作为主键还有一个长处:当你拥有一致的键构造时,找到逻辑缺陷很简单.
3. 分化字段用于索引
为了别离命名字段和包含字段以支持用户定义的报表,请考虑分化其他字段（乃至主键）为其构成要素以便用户可以对其举行索引.索引将加快SQL 和报表生成器脚本的履行速度.比方说,我普通在必须利用SQL LIKE 表达式的情形下成立报表,因为case number 字段无法分化为year、serial number、case type 和defendant code 等要素.性能也会变坏.假定年度和范例字段可以分化为索引字段那么这些报表运行起来就会快多了.
4. 键计划4 原则
· 为关联字段成立外键.
· 全部的键都必须唯一.
· 避免利用复合键.
· 外键老是关联唯一的键字段.
5. 别忘了索引
索引是从数据库中获得数据的最高效方法之一.95%的数据库性能问题都可以采取索引技术得到办理.作为一条法则,我普通对逻辑主键利用唯一的成组索引,对系统键（作为存储历程）采取唯一的非成组索引,对任何外键列采取非成组索引.不过,索引就象是盐,太多了菜就篌了.你得考虑数据库的空间有多大,表若何举行拜候,还有这些拜候能否主要用作读写.
大大都数据库都索引自动成立的主键字段,但是可别忘了索引外键,它们也是常常利用的键,比方运行查询显示主表和全部关联表的某条记录就用得上.还有,不要索引memo/note 字段,不要索引大型字段（有很多字符）,这样作会让索引占用太多的存储空间.
6. 不要索引常用的小型表
不要为小型数据表设置任何键,假定它们常常有插入和删除操作就更别这样作了.对这些插入和删除操作的索引保护大概比扫描表空间损耗更多的时间.
7. 不要把社会保障号码（SSN）选作键
永久都不要利用SSN 作为数据库的键.除了隐私缘由以外,须知政府越来越趋向于不准许把SSN 用作除收入相关以外的其他目的,SSN 需求手工输入.永久不要利用手工输入的键作为主键,因为一旦你输入错误,你唯一能做的就是删除整个记录然后重新开始.
上个世纪70 年代我还在读大学的时刻,我记得当时SSN 还曾被用做学号,当然固然这么做是不法的.并且人们也都知道这是不法的,但他们已经习惯了.后来,随着盗取身份犯罪案件的增添,我目前的大学校园正痛楚地从一大摊子数据中把SSN 删除.
8. 不要用用户的键
在肯定采取什么字段作为表的键的时刻,可一定要当心用户将要编辑的字段.普通的情形下不要挑选用户可编辑的字段作为键.这样做会迫使你采纳以下两个办法:
· 在成立记录之后对用户编辑字段的行为施加限制.假定你这么做了,你大概会发现你的利用程序在商务需求忽然发生改变,而用户需求编辑那些不可编辑的字段时贫乏充足的机动性.当用户在输入数据之后直到保存记录才发现系统出了问题他们该怎么想?删除重建?假定记录不可重建能否让用户走开?
· 提出一些检测和改正键冲突的办法.普通,费点精神也就搞定了,但是从性能上来看这样做的代价就对比大了.还有,键的改正大概会迫使你冲破你的数据和商业/用户界面层之间的断绝.
所以还是重提一句老话:你的计划要适利用户而不是让用户来适应你的计划.
不让主键具有可更新性的缘由是在关系情势下,主键实现了差别表之间的关联.比方,Customer 表有一个主键CustomerID,而客户的订单则存放在另一个表里.Order 表的主键大概是OrderNo 大概OrderNo、CustomerID 和日期的组合.不管你挑选哪类键设置,你都需求在Order 表中存放CustomerID 来保证你可以给下订单的用户找到其订单记录.
假定你在Customer 表里改正了CustomerID,那么你必须找出Order 表中的全部相关记录对其举行改正.不然,有些订单就会不属于任何客户——数据库的完好性就算完蛋了.
假如索引完好性法则施加到表一级,那么在不编写大量代码和附加删除记录的情形下几近不大概改变某一条记录的键和数据库内全部关联的记录.而这一历程常常错误丛生所以应当尽大概避免.
9. 可选键有时可做主键
记着,查询数据的不是机械而是人.
假定你有可选键,你大概进一步把它用做主键.那样的话,你就拥有了成立强盛索引的本领.这样可以禁止利用数据库的人不得不衔接数据库从而得当的过滤数据.在严峻掌握域表的数据库上,这种负载是对比夺目的.假如可选键真正有效,那就是到达了主键的水准.
我的见解是,假定你有可选键,比方国家表内的state_code,你不要在现有不能变更的唯一键上成立后续的键.你要做的无非是成立毫无代价的数据.比方以下的例子:
10. 别忘了外键
大大都数据库索引自动成立的主键字段.但别忘了索引外键字段,它们在你想查询主表中的记录及其关联记录时每次城市用到.还有,不要索引memo/notes 字段并且不要索引大型文本字段（很多字符）,这样做会让你的索引占据大量的数据库空间.
第4 部份— 保证数据的完好性
1. 用约束而非商务法则强迫数据完好性
假如你按照商务法则来处理需求,那么你该当查抄商务层次/用户界面:假如商务法则今后发生改变,那么只需求举行更新便可.
假定需求源于保护数据完好性的需求,那么在数据库层面上需求施加限制条件.
假如你在数据层确切采取了约束,你要保证有办法把更新不能通过约束查抄的缘由采取用户理解的语言告诉用户界面.除非你的字段命名很冗长,不然字段名本身还不够.
Select count(*)
from address, state_ref
where
address.state_id = state_ref.state_id
and state_ref.state_code = 'TN'
我的做法是这样的:
Select count(*)
from address
where
and state_code = 'TN'
如你因为过度利用表的后续键成立这种表的关联,操作负载真得需求考虑一下了.
只要有大概,请采取数据库系统实现数据的完好性.这不但包含通过尺度化实现的完好性并且还包含数据的功效性.在写数据的时刻还可以增添触发器来保证数据的精确性.不要依靠于商务层保证数据完好性;它不能保证表之间（外键）的完好性所以不能强加于其他完好性法则之上.
2. 分布式数据系统
对分布式系统而言,在你决意能否在各个站点复制全部数据还是把数据保存在一个地方之前应当预计一下将来5 年大概10 年的数据量.当你把数据传送到其他站点的时刻,最好在数据库字段中设置一些标志.在目的站点收到你的数据之后更新你的标志.为了举行这种数据传输,请写下你自己的批处理大概调度程序以特按时间隔断运行而不要让用户在每天的工作后传输数据.本地拷贝你的保护数据,比方计算常数和利钱率等,设置版本号保证数据在每个站点都完好一致.
3. 强迫指导完好性
没有好办法能在有害数据进入数据库之后消除它,所以你应当在它进入数据库之前将其剔除.激活数据库系统的指导完好性特点.这样可以保持数据的洁净而能迫使开辟人员投入更多的时间处理错误条件.
4. 关系
假如两个实体之间存在多对一关系,并且还有大概转化为多对多关系,那么你最好一开始就设置成多对多关系.从现有的多对一关系改变成多对多关系比一开始就是多对多关系要可贵多
以上是“数据库计划指南（三）[MSSQL防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
- ·上一篇文章：数据库计划指南（四）
- ·下一篇文章：数据库编程经验两则
- ·
中查找“数据库计划指南（三）”更多相关内容 - ·
中查找“数据库计划指南（三）”更多相关内容
评论内容只代表网友观点，与本站立场无关！
评论摘要(共 0 条，得分 0 分，平均 0 分)
查看完整评论