“预留字段”——你想对了吗？

        前两天，米老师对我们的基础系统进行了阶段性验收，由“预留字段”拉开了米老师对我们思想（或者说是思维方式）深刻的剖析序幕。

一、花开两朵，先表“预留字段”这一枝！

        现象描述：
        在数据表中，不仅设计了当前所需要的字段，而且还在其中留出几个字段作为备用。比方说，我设计了一个人员表（Person），其中已经添加了各种必要的字段，包括姓名（Name）、性别（Sex）、出生年月日（birthday）等等。大功告成之后，我忽然想到，将来系统中应该还会有很多其它与人相关的内容吧，比方说毕业院校，比方说政治面貌等等，尽管现在根本不需要填写，以后可能还是会用到的吧。拍脑袋一想，那就加入5个varchar型的字段，分别叫做other1、other2……other5，然后又想，应该还有一些日期型的字段需要备用，就又建立了三个date型的字段，分别起名叫做date1、date2、date3，……
        原因分析：
        大家应该已经看出问题了，在这个数据表中存在大量暂时无用的字段，我们可以称之为预留字段，它们的作用是什么呢？就是以防万一，防备可能的情况。
        这似乎可以叫做防患于未然，等到时候需要的时候，就不需要在表中增加新的字段了，而且这样做的话，一个表的数据应该会被存储在相邻的物理空间中，这对于性能也是有好处的。
        问题所在：
        这样的做法对于项目会导致很多问题，而且原先想要解决的问题并不一定能够解决，不信的话，请往下看。
        问题一：增加大量备用字段，必定会浪费很多空间，尽管其中可能都没有具体的数据，但是仅仅是空字段也会占据一定的空间的。
        问题二：由于命名的特点，如果没有完善的文档管理流程，用不了多久，就没有人能够说清楚到底哪个字段代表的是什么意义了。就算有文档管理，这些管理工作也会比较麻烦吧。
        问题三：增加了这些备用字段就真的会够用吗？不一定，因为我们只是每个类型的字段留出几个备用，如果数量超过，或者要使用特殊的、不常用的类型的时候，还是需要增加新的字段。比方说在上述的Person表中，我们要存储照片呢？这在初期设计的时候可不一定会留出相应的预留字段。而且如果没有完善的管理，谁又能说清楚倒底哪个字段已经被使用，哪个字段还可以使用呢？到时候还不是要增加新的字段。
        解决方案：
        其实上面的这种设计方式就是一种“过度设计”，我们应该做的就是“按需设计”，在经过详细有效的分析之后，在数据表中只放置必要的字段，而不要留出大量的备用字段。
        当需要增加相关的信息的时候，就要具体情况具体分析：
        如果数量很少，而且信息的性质与原表密切相关，那么就可以直接在原表上动态增加字段，并将相关的数据更新进去。
        如果数量较大，或者并非是原表对象至关重要的属性，那么就可以新增一个表，然后通过键值连接起来。

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

二、下面谈谈其中暴露出来的思想问题！
        其实在“善良公社”时，数据库设计时也使用了。当时为什么没想“预留字段”的利与弊呢？米老师说：为什么不使用动态添加字段呢？“预留字段”表面上感觉是挺好的，但他是否会带来负面影响，这些影响会有多大？
         说实话，头脑中真没想过这个，“动态”这个概念就没深入自己脑子过。米老师分析了我们的思维方式，打骨子里，我们就想一劳永逸，数据库一次性设计完就OK了。不去想变化是无处不在的，而且是各色各样的的，我们不愿意去面对变化。当事情变化的时候，我们往往会手忙脚乱，我们想偷懒，这样的结果却是——增加了无数的麻烦。内心深处，我们希望什么都别变，然后就高枕无忧啦！但这社会确实是一个充满了变化的，唯一不变是就是“变”——变是永远不变的。我们老是自作聪明，总是希望找到一种方式能面对所有的变数。于是我们想到了“预留字段”，然后大笑一声，我可真聪明，这下就不怕增字段了。结果呢？？？？
        对于我们来说，技术确实是小case，任何人都没问题，“思想”才是无价的，给带来的财富，也将是无穷的，而我们总是在思想上偷懒，这也是为什么我们考不上清华北大的原因。我们在矢志不渝的维护自己的过去，自己的历史，不去改变。我们真的很聪明，我们绝对不输清华北大，但差在哪了？——我们的聪明都用在偷懒上了！
        回头看看，每个人都在进步，但为何大多数都进步那么慢？——懒！改变是痛苦的，但不改，我们很难产生蜕变。凤凰涅槃，每个人都渴望破茧成蝶，那么就改变坏习惯，从最本质的“思想”开始！