数据库设计技巧

很久以前……我不是讲故事，而是很久之前就下了一篇关于数据库设计技巧的书 ，貌似应该是老外写的，最近才看，做一下笔记

 

检查各种变化
我在设计数据库的时候会考虑到哪些数据字段将来可能会发生变更。比方说，姓氏就是如此（注
意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，我倾向于
在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一
数据条目的变化。

 

采用常用实体命名机构数据
组织数据的最简单办法就是采用常用名字，比如：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 等。
采用一般抽象术语来标识“事物”的类别可以让你在关联数据以满足业务要求方面获得巨大的灵
活性，同时这样做还可以显著降低数据存储所需的冗余量。

 

用户来自世界各地
在设计用到网络或者具有其他国际特性的数据库时，一定要记住大多数国家都有不同的字段格
式，比如邮政编码等，有些国家，比如新西兰就没有邮政编码一说。

 

 

别忘了索引
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到
解决。作为一条规则，我通常对逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用
唯一的非成组索引，对任何外键列采用非成组索引。不过，索引就象是盐，太多了菜就篌了。你
得考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。

 

不要把社会保障号码（SSN）选作键
永远都不要使用SSN 作为数据库的键。除了隐私原因以外，须知政府越来越趋向于不准许把
SSN 用作除收入相关以外的其他目的，SSN 需要手工输入。永远不要使用手工输入的键作为主
键，因为一旦你输入错误，你唯一能做的就是删除整个记录然后从头开始。

上个世纪 70 年代我还在读大学的时候，我记得那时SSN 还曾被用做学号，当然尽管这么做是非
法的。而且人们也都知道这是非法的，但他们已经习惯了。后来，随着盗取身份犯罪案件的增
加，我现在的大学校园正痛苦地从一大摊子数据中把SSN 删除。