选取键和目录

 

选取键和目录

  1. 数码采掘要预先布署

自我所在的商海部门曾经要拍卖8
万多份联系形式,同时填写每个客户的画龙点睛数据(那纯属不是小活)。我从中还要确定出一组客户作为市场目的。当自家从早先河设计表和字段的时候,我打算不在主索引里增添太多的字段以便加速数据库的周转速度。然后自己发现到特定的组查询和音讯采掘既不纯粹速度也伤心。结果不得不在主索引中重建而且合并了多少字段。我发现有一个提示布置极度重大——当自己想创立系统项目查找时怎么要运用号码作为主索引字段呢?我得以用传真号码进行检索,不过它大致就象系统项目一样对本人的话并不主要。接纳后者作为主字段,数据库更新后再一次索引和搜索就快多了。

— hscovell

可操作数据仓库(ODS)和数据仓库(DW)那两种环境下的数目索引是有差别的。在DW
环境下,你要考虑销售机构是怎么着协会销售移动的。他们并不是数据库管理员,可是她们确定表内的键音讯。那里设计人士或者数据库工作人士应该分析数据库结构从而确定出质量和正确输出之间的最佳标准。

— teburlew

  1. 选拔系统生成的主键

这一天类同技术1,但本身认为有必要在此间再度提醒我们。借使你总是在设计数据库的时候使用系统生成的键作为主键,那么你其实控制了数据库的目录完整性。那样,数据库和非人工机制就有效地控制了对存储数据中每一行的造访。

行使系统生成键作为主键还有一个优点:当你有着一致的键结构时,找到逻辑缺陷很不难。

— teburlew

  1. 解说字段用于索引

为了分离命名字段和富含字段以支撑用户定义的表格,请考虑分解其余字段(甚至主键)为其重组元素以便用户可以对其开展索引。索引将加快SQL
和表格生成器脚本的执行进度。比方说,我一般在必须采纳SQL LIKE 表明式的境况下创办报表,因为 case number 字段不可能分解为year、serial number、case type 和defendant code
等元素。质量也会变坏。即使年度和种类字段可以解释为索引字段那么这一个报表运行起来就会快多了。

— rdelval

  1. 键设计4 原则

· 为涉嫌字段成立外键。

· 所有的键都必须唯一。

· 幸免使用复合键。

· 外键总是关联唯一的键字段。

— Peter Ritchie

  1. 别忘了索引

目录是从数据库中获取数据的最便捷方式之一。95%的数据库质量难题都可以应用索引技术取得化解。作为一条规则,我平常对逻辑主键使用唯一的成组索引,对系统键(作为存储进度)采纳唯一的非成组索引,对其他外键列拔取非成组索引。但是,索引就象是盐,太多了菜就篌了。你得考虑数据库的半空中有多大,表怎么着进展访问,还有那些访问是不是紧要用作读写。

— tduvall

一大半数据库都引得自动创立的主键字段,然而可别忘了目录外键,它们也是日常使用的键,比如运行查询突显主表和装有关联表的某条记下就用得上。还有,不要索引memo/note
字段,不要索引大型字段(有广大字符),那样作会让索引占用太多的积存空间。

— gbrayton

  1. 永不索引常用的小型表

无须为小型数据表设置任何键,假设它们平日有插入和删除操作就更别那样作了。对那么些插入和删除操作的目录维护可能比扫描表空间消耗越来越多的岁月。

— kbpatel

  1. 绝不把社会保证号码(SSN)选作键

永久都毫无采用SSN
作为数据库的键。除了隐衷原因以外,须知政党更是趋向于不批准把SSN 用作除收入有关以外的别的目标,SSN
要求手工输入。永远不要使用手工输入的键作为主键,因为假使您输入错误,你唯一能做的就是去除所有记录然后从头先河。

— teburlew

上个世纪70
年代我还在读大学的时候,我记得当时SSN
还曾被用做学号,当然即使那样做是私自的。而且人们也都了然那是地下的,但她俩早就不以为奇了。后来,随着盗取身份犯罪案件的增多,我现在的高校校园正忧伤地从一大摊子数据中把SSN 删除。

— generalist

  1. 毫无用用户的键

在确定接纳什么字段作为表的键的时候,可一定要小心用户即将编辑的字段。常常的情形下不要选用用户可编制的字段作为键。那样做会迫使你选用以下多少个点子:

·
在开创记录之后对用户编辑字段的行为施加限制。如果你这么做了,你恐怕会意识你的应用程序在商务必要旱地拔葱,而用户须求编制那一个不可编辑的字段时缺少丰硕的八面驶风。当用户在输入数据之后直到保存记录才意识系统出了问题他们该怎么想?删除重建?假诺记录不可重建是不是让用户走开?

·
提议一些检测和校对键龃龉的不二法门。平常,费点精力也就搞定了,不过从质量上来看这么做的代价就比较大了。还有,键的勘误或者会迫使你突破你的数据和商业/用户界面层之间的割裂。所以依旧重提一句古语:你的筹划要适应用户而不是让用户来适应你的统筹。

— Lamont Adams

不让主键具有可更新性的由来是在关系形式下,主键完成了差异表之间的涉及。比如,

Customer 表有一个主键CustomerID,而客户的定单则存放在另一个表里。Order 表的主键可能

是OrderNo 或者OrderNo、CustomerID
和日期的整合。不管您选取哪类键设置,你都须求在Order 表中存放CustomerID
来有限支撑你可以给下定单的用户找到其定单记录。

设若你在Customer 表里修改了CustomerID,那么您不可以不找出Order
表中的所有相关记录对其进行修改。否则,有些定单就会不属于此外客户——数据库的完整性固然完蛋了。

一旦索引完整性规则施加到表一流,那么在不编写大批量代码和附加删除记录的境况下大概无法改动某一条记下的键和数据库内享有涉嫌的笔录。而这一历程往往错误丛生所以应该尽量防止。

— ljboast

  1. 可选键有时可做主键

难忘,查询数据的不是机械而是人。

倘若你有可选键,你或许一发把它用做主键。那样的话,你就有着了创立强有力索引的力量。这样可以阻碍使用数据库的人只能三番五次数据库从而恰当的过滤数据。在严苛控制域表的数据库上,那种负荷是比较显明的。若是可选键真正有用,那就是达到了主键的水准。

必发娱乐最新官方网址,本人的见解是,若是你有可选键,比如国家表内的state_code,你绝不在现有无法更改的绝无仅有键上创制后续的键。你要做的仅仅是创设毫无价值的多寡。比如以下的例子:

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’

如你因为过分使用表的后续键建立那种表的关系,操作负载真得须要考虑一下了。

— Stocker

  1. 别忘了外键

一大半数据库索引自动创制的主键字段。但别忘了索引外键字段,它们在您想询问主表中的记录及其关系记录时每趟都会用到。还有,不要索引memo/notes
字段而且不用索引大型文本字段(许多字符),那样做会让你的目录占据多量的数据库空间。。

— gbrayton

__

发表评论

电子邮件地址不会被公开。 必填项已用*标注