等考三级数据库设计经验谈3-选择键和索引.docxVIP

等考三级数据库设计经验谈3:选择键和索引 第一局部介绍了设计数据库之前12个根本技巧，包括命名标准和明确业务需求等(数据库设计阅历谈 (1) )；其次局部介绍设计数据库表24个指南性技巧，涵盖表内字段设计以及应当避开的常见问题等(数据库设计阅历谈 (2) )；本次第三局部主要介绍选择键和索引，包含10个技巧特地涉及系统生成的主键的正确用法，还有何时以及如何索引字段以获得性能等。第 3 局部 - 选择键和索引数据采掘要预先打算　　我所在的某一客户部门一度要处理 8 万多份联系方式，同时填写每个客户的必要数据（这肯定不是小活）。我从中还要确定出一组客户作为市场目标。当我从最开头设计表和字段的时候，我试图不在主索引里增加太多的字段以便加快数据库的运行速度。然后我意识到特定的组查询和信息采掘既不精确速度也不快。结果只好在主索引中重建而且合并了数据字段。我发觉有一个指示打算相当关键——当我想创立系统类型查找时为什么要采纳号码作为主索引字段呢？我可以用传真号码进展检索，但是它几乎就象系统类型一样对我来说并不重要。采纳后者作为主字段，数据库更新后重新索引和检索就快多了。　　可操作数据仓库（ods）和数据仓库（dw）这两种环境下的数据索引是有差异的。在 dw 环境下，你要考虑销售部门是如何组织销售活动的。他们并不是数据库治理员，但是他们确定表内的键信息。这里设计人员或者数据库工作人员应当分析数据库构造从而确定出性能和正确输出之间的条件。使用系统生成的主键　　这类同技巧 1，但我觉得有必要在这里重复提示大家。假设你总是在设计数据库的时候采纳系统生成的键作为主键，那么你实际掌握了数据库的索引完整性。这样，数据库和非人工机制就有效地掌握了对存储数据中每一行的访问。　　采纳系统生成键作为主键还有一个优点：当你拥有全都的键构造时，找到规律缺陷很简单。分解字段用于索引　　为了分别命名字段和包含字段以支持用户定义的报表，请考虑分解其他字段（甚至主键）为其组成要素以便用户可以对其进展索引。索引将加快 sql 和报表生成器脚本的执行速度。比方说，我通常在必需使用 sql like 表达式的状况下创立报表，由于 case number 字段无法分解为 year、serial number、case type 和 defendant code 等要素。性能也会变坏。假设年度和类型字段可以分解为索引字段那么这些报表运行起来就会快多了。键设计 4 原则　　1.为关联字段创立外键。　　2.全部的键都必需。　　3.避开使用复合键。　　4.外键总是关联的键字段。别忘了索引　　索引是从数据库中猎取数据的效方式之一。95% 的数据库性能问题都可以采纳索引技术得到解决。作为一条规章，我通常对规律主键使用的成组索引，对系统键（作为存储过程）采纳的非成组索引，对任何外键列[字段]采纳非成组索引。不过，索引就象是盐，太多了菜就咸了。你得考虑数据库的空间有多大，表如何进展访问，还有这些访问是否主要用作读写。　　大多数数据库都索引自动创立的主键字段，但是可别忘了索引外键，它们也是常常使用的键，比方运行查询显示主表和全部关联表的某条记录就用得上。还有，不要索引 memo/note 字段，不要索引大型字段（有许多字符），这样作会让索引占用太多的存储空间。不要索引常用的小型表　　不要为小型数据表设置任何键，假设它们常常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。不要把社会保障号码（ssn）或身份证号码（id）选作键　　永久都不要使用 ssn 或 id 作为数据库的键。除了隐私缘由以外，须知政府越来越趋向于不准许把 ssn 或 id 用作除收入相关以外的其他目的，ssn 或 id 需要手工输入。永久不要使用手工输入的键作为主键，由于一旦你输入错误，你能做的就是删除整个记录然后从头开头。　　我在破解他人的程序时候，我看到许多人把 ssn 或 id 还曾被用做系列号，固然尽管这么做是非法的。而且人们也都知道这是非法的，但他们已经习惯了。后来，随着盗取身份犯罪案件的增加，我现在的同行正苦痛地从一大摊子数据中把 ssn 或 id 删除。不要用用户的键　　在确定采纳什么字段作为表的键的时候，可肯定要当心用户将要编辑的字段。通常的状况下不要选择用户可编辑的字段作为键。这样做会迫使你实行以下两个措施：　　1.在创立记录之后对用户编辑字段的行为施加限制。假设你这么做了，你可能会发觉你的应用程序在商务需求突然发生变化，而用户需要编辑那些不行编辑的字段时缺乏足够的敏捷性。当用户在输入数据之后直