写在前面：本来“程序员应知”系列中应该写的都是与程序员密切相关的内容，而数据库设计似乎应该是数据库管理员的工作。然而，在实际的工作环境中，我所经历几乎所有的项目中，数据库设计工作都是由程序员来完成的；就算我们是不需要做数据库设计的程序员，也至少需要对数据库的结构有充分的理解，那样也便于我们编写和维护系统。思量再三，我还是将这篇与数据库设计相关的文章放在了这个系列当中。

　　在几乎所有的企业级应用程序中，包括各种MIS、ERP、CRM等等，都会使用数据库，这样的好处是显而易见的，很容易地实现了数据层和业务逻辑层的分离，而且对于性能的优化也在一定程度上提供了便利。

　　然而，在我所经历过的项目中，某些数据库的设计会存在一些问题，尤其普遍的就是下面将要描述的这两点，个人觉得是应该避免的误区，总结出来与大家讨论。

　　误区之一 备用字段

　　现象描述：

　　在数据表中，不仅设计了当前所需要的字段，而且还在其中留出几个字段作为备用。

　　比方说，我设计了一个人员表（Person），其中已经添加了各种必要的字段，包括姓名（Name）、性别（Sex）、出生年月日（birthday）等等。大功告成之后，我忽然想到，将来系统中应该还会有很多其它与人相关的内容吧，比方说毕业院校，比方说工作单位等等，尽管现在根本不需要填写，以后可能还是会用到的吧。拍脑袋一项，那就加入5个varchar2型的字段，分别叫做Text1、Text2……Text5，然后又想，应该还有一些日期型的字段需要备用，就又建立了三个date型的字段，分别起名叫做date1、date2、date3，……

　　原因分析：

　　大家应该已经看出问题了，在这个数据表中存在大量暂时无用的字段，我们可以称之为备用字段，它们的作用是什么呢？就是以防万一，防备可能的情况。

　　这似乎可以叫做防患于未然，等到时候需要的时候，就不需要在表中增加新的字段了，而且这样做的话，一个表的数据应该会被存储在相邻的物理空间中，这对于性能也是有好处的。

　　另外的原因就是，在古老的数据库中，如果改变数据库的定义（包括增加字段、改变字段的类型、删除字段等等），那么其中所有的数据就会丢失，所以这项工作非常麻烦，我们需要先建立临时表，将数据备份出来，然后创建新表，将数据导入其中，最后再删除原来的表。

　　问题所在：

　　这样的做法对于项目会导致很多问题，而且原先想要解决的问题并不一定能够解决，不信的话，请往下看。

　　问题一：增加大量备用字段，必定会浪费很多空间，尽管其中可能都没有具体的数据，但是仅仅是空字段也会占据一定的空间的。

　　问题二：由于命名的特点，如果没有完善的文档管理流程，用不了多久（可能也就是两三年），就没有人能够说清楚到底哪个字段代表的是什么意义了。就算有文档管理，这些管理工作也会比较麻烦，而且在每次使用的时候都需要申请，还有可能会出现冲突的情况。

　　问题三：增加了这些备用字段就真的会够用吗？不一定，因为我们只是每个类型的字段留出几个备用，如果数量超过，或者要使用特殊的、不常用的类型的时候，还是需要增加新的字段。比方说在上述的Person表中，我们要存储照片，那么可能就要增加一个blob类型的photo字段，这在初期设计的时候可不一定会留出这样的备用字段。而且如果没有完善的管理，谁又能说清楚倒底哪个字段已经被使用，哪个字段还可以使用呢？到时候还不是要增加新的字段。

　　解决方案：

　　其实上面的这种设计方式就是一种“过度设计”，我们应该做的就是“按需设计”，在经过详细有效的分析之后，在数据表中只放置必要的字段，而不要留出大量的备用字段。

　　当需要增加相关的信息的时候，就要具体情况具体分析：

　　如果数量很少，而且信息的性质与原表密切相关，那么就可以直接在原表上增加字段，并将相关的数据更新进去。

　　如果数量较大，或者并非是原表对象至关重要的属性，那么就可以新增一个表，然后通过键值连接起来。

　　对于表的数据的存储位置所导致的性能问题，我们可以通过在特定时间对数据库的数据进行重组来解决，而这项工作对于长期运行的数据库来说，也是需要定期进行的。