经验04 技高一筹——数据库设计经验谈

凡事预则立，不预则废。

——摘自《礼记•中庸》

数据库设计在实际的项目开发中占有十分重要的地位，数据库设计的好坏涉及一个项目的成败。俗话说“再好的老师也比不过经验的教诲”，所以归纳历年来我所走的弯路及体会，总结了一些数据库设计的经验和技巧，希望对大家有所帮助。

1.开始设计数据库前分析现有的系统的表结构

在设计一个新数据库时，不但应该仔细研究项目的业务需求，而且还要分析现有的系统的表结构。大多数的项目数据库都不是从头开始建立的（除非这个机构在此之前没有进行过任何的信息化工作），通常，项目原来总会存在用来满足特定需求的现有系统，分析原来的系统会帮助设计人员更快地了解业务流程。显然，现有的系统并不完美，或者已经无法满足现有的业务要求。

说明

对旧系统的研究可以让设计人员发现一些可能会忽略的细微问题。一般来说，考察现有系统对数据库设计人员来说是非常有意义的。

2.尽早创建系统的ER图

在项目设计阶段一定要花点时间创建ER图，其中至少要包括每个字段的数据类型和表的主外键，虽然创建ER图有点费时，但是它可以让其他开发人员了解数据库的整个设计，让他们明确如何与数据库进行交互，了解系统的业务流程，保持团队思路的一致，从而避免今后开发中可能遇到的混乱问题，总之一张图表胜过千言万语。

3，标准化和数据驱动

数据的标准化不仅方便了自己也方便了其他人。如果数据库采用数据驱动而非硬编码的方式，那么策略变更和维护都会方便很多。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。

注意

不能对数据库过分标准化，过分标准化会为数据库引入过高的复杂性，造成数据库的效率低下。

4.不要将身份证号码选做表的主键

虽然身份证号是唯一的，但是也不要使用它来当做表的主键，因为使用手工输入的数据作为主键，一旦你输入错误，唯一能做的就是删除整条记录然后重新开始。利用身份证号码作为表的主键对于信息而言也是不安全的。在数据库设计中，利用身份证号码或其他证件号码作为表的主键是完全非法的。

提示

数据库键设计四原则：为关联字段创建外键；所有键都必须唯一；避免使用复合键；外键总是关联唯一的键字段。

5.保证数据的完整性

只要有可能，就利用数据库系统实现数据的完整性。其实利用主外键的设置就可以达到保证数据完整性的要求，数据不能依赖于业务层保证数据完整性，它不能保证表之间（外键）的完整性，所以不能强加于其他完整性规则之上。

提示

如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。除非你的字段命名很冗长，否则字段名本身还不够。

6.为文本字段留足字段余量

以产品编号类型的文本字段为例，比如产品编号或者用户ID等都应该设置为比预计的更大，因为字段随时有增长的可能。假设产品编号为10位数长。那就应该把数据库表字段的长度设为13个字符长或者更长。设计人员一定会问：“这算浪费空间吗？”，其实是有一点浪费时间，但是没你想象的那么多，在多数项目中，这些空间可以忽略不计。但这额外占据的空间却无须将来重构整个数据库就可以实现数据库规模的增长了。

说明

一般数据库所有的字段长度都应该比预期的长一些，除了个别的字段以外（例如数据库自动生成的ID），这种有弹性的设计使数据库的设计更具健壮性。

7.使用系统生成的主键

假如在设计数据库的时候采用系统生成的键作为主键，那么实际上就已经控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点，就是当拥有一致的键结构时，设计人员查找逻辑缺陷将更容易。

8.反复测试设计的数据库

当数据库设计完毕后，最好让用户和开发人员一起测试数据库，让用户输入正式的数据测试数据库的各个字段是否可以满足业务需求，这是最好的测试手段之一，测试工作需要在系统正式投入使用前完成。

编程加油站：数据库设计技巧学习建议

关于数据库的设计技巧，也不是三言两语就能说清的，对于感兴趣的开发人员，可以先了解数据库的设计规范再去学习数据库设计的各种方法。数据库设计的难度就在于如何把用户的需求抽象成一张张关联的数据表，而这也并非设计人员一朝一夕练就成的，这需要经验和理论的结合。所以重要的是多积累，在以程序员身份开发项目的时候多想想数据库为什么这么设计？这么设计有什么优点？有没有更好的设计方案？多想多做才是成功之道。