数据库设计指南.docVIP

数据库设计指南 保密文件 不得外传 文档修订记录 版本编号 *变化 状态 简要说明（变更内容和变更范围） 日期 变更人 批准日期 批准人 V0.1 建立 V1.0 *变化状态：建立，修改，增加，删除 文档审批信息 序号 审批人 角色 审批日期 签字 备注 1 主 要 内 容 1 引言 1 1.1 编写目的 1 1.2 内容范围 1 1.3 读者对象 1 1.4 术语定义 1 1.5 参考资料 1 2 设计表和字段 1 2.1 检查各种变化 1 2.2 采用有意义的字段名 2 2.3 采用前缀命名 2 2.4 标准化不能过头 2 2.5 不活跃或者不采用的指示符 3 2.6 采用常用实体命名机构数据 3 2.7 数据重复需要采用分立的数据表 3 2.8 小心保留词 3 2.9 保持字段名和类型的一致性 4 2.10 删除标记 4 2.11 避免使用触发器 4 2.12 包含版本机制 4 3 索引 5 3.1 功能列表 5 3.2 分解字段用于索引 5 3.3 键设计4原则 5 3.4 不要索引常用的小型表 5 3.5 别忘记外键 6 引言 编写目的 本指南收集了一些数据库设计方面的建议和技巧，为数据库设计人员在进行设计时提供一些参考。 内容范围 本指南包含一些数据库设计的建议和技巧。 读者对象 数据库设计人员 开发人员 术语定义 参考资料 设计表和字段 检查各种变化 考虑到哪些数据字段将来可能会发生变更在建立系统存储信息时，在单独的一个数据表里存储，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。 除非你在使用只面向你的缩写字段名的系统，否则请尽可能地把字段描述的清楚些。也别做过头了，比如Customer_Shipping_Address_Street_Line_1 I 虽然很富有说明性，但没人愿意键入这么长的名字，具体尺度就在你的把握中 。 采用前缀命名 如果多个表里有好多同一类型的字段 （比如FirstName），你不妨用特定表的前缀 （比如 CusLastName）来帮助你标识字段。 时效性数据应包括 “最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用 遵守3NF 标准的数据库具有以下特点：有一组表专门存放通过键连接起来的关联数据。比方说，某个存放客户及其有关定单的3NF 数据库就可能有两个表：Customer 和 Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer 表里包含该客户信息的那一行。 更高层次的标准化也有，但更标准是否就一定更好呢？答案是不一定。事实上，对某些项目来 说，甚至就连3NF 都可能给数据库引入太高的复杂性为了效率的缘故，对表不进行标准化有时也是必要的，这样的例子很多。绝不把数据表的非标准化当作当然的设计理念。而具体的操作不过是一种派生。所以如果表出了问题重新产生非标准化的表是完全可能的。 增加一个字段表示所在记录是否在业务中不再活跃挺有用的。不管是客户、员工还是其他什么人，这样做都能有助于再运行查询的时候过滤活跃或者不活跃状态。同时还消除了新用户在采用数据时所面临的一些问题，比如，某些记录可能不再为他们所用，再删除的时候可以起到一定的防范作用。 组织数据的最简单办法就是采用常用名字，比如：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等。 采用一般抽象术语来标识“事物”的类别可以让你在关联数据以满足业务要求方面获得巨大的灵活性，同时这样做还可以显著降低数据存储所需的冗余量。 如果你发现自己在重复输入数据，请创建新表和新的关系。 在命名字段并为其指定数据类型的时候一定要保证一致