倒不是我想把一篇文章拆成两部分来赚取人气，不过是希望在这之间，能够给大家一点儿思考的时间。
在上一篇文章中我们提出了一个问题“到底是什么束缚了我们的思想”。
先来看一下上一篇文章的一个回复：
“序列化实例？
有没有想过啊，要是某一天需求变了，你的类有所变动了，数据库里面的成千上万的数量都废了啊”
——月の树
这是很有代表性的一个问题， 冗余的数据真的会在需求变更时变成垃圾么？
那么接下来就让我们继续来探求下客户到底可能怎么变更吧：
1、客户说，我们“科技图书”需要增加一个属性，用来指示这种图书是“译文本”、“原文本”还是“中文本”。如果数据库中没有数据，我们怎么重构程序也不会有什么问题。现在假设数据库中已经存在大量数据，增加一个属性原来的数据如何处理呢？分成下列几种情况：
a> 客户说，之前的数据全部作废。哇咧~~~……这种客户真是贴心啊，如果客户说之前的数据全部作废的话，情况就和数据库里面没有数据一样了，我们完全不用考虑兼容啊，迁移什么问题。
在分析接下来的问题前，我们先对OO结构做一些重新的设计：假设原来的“科技图书”类不变，为了应付新增的需求，我们设计了一个新的“科技图书2”的类，该类比原先的类增加了一个属性来满足新增的需求。
b> 客户说，之前的数据默认是“中文本”的好了。在这种情况下，我们有必要对原有的序列化数据全部进行更新么？不需要，在反序列化的时候我们是完全可以植入自己的逻辑的，我们可以非常简单的将“科技图书”对象转换为“科技图书2”对象。（嗯，如果你觉得“科技图书2”这个名字不好听，其实也是完全可以解决的，在此不详述）。
c> 客户说，之前的数据全部撤下，给我一个后台，将这些图书数据全部添加上新的属性。与上面同样的原理，我们可以设计一个新的“科技图书2”的表，然后制作一个后台协助客户将数据从“科技图书”表更新到“科技图书2”表。
d> 客户说，旧的数据呈现的时候就不显示新的属性，新录入的数据则必须具备这些新的属性。这个其实就是以特殊值( null? )来作为默认值罢了，与b种情况是相同的。
2、客户说，我们要去掉一个属性。屏蔽功能即可，数据结构不变，或者完全敲定后重构。
3、客户说，我们要变更一个属性。屏蔽原属性功能够增加新属性即可。
数据的冗余会带来同步成本，带来不一致的风险，所以我们在潜意识中对冗余的设计进行抵触。在解决问题时，我们不得不接受诸如“科技图书2”这种别扭的名字来解决一些问题，或者其中的一些问题超出了我们的知识范畴（在反序列化的时候植入自己的逻辑）而感到恐惧。
尝试分析一下，是我们追求完美的思维束缚了我们的思维，这样的需求怎么更高在OOD里面都会是干干净净的对象结构。但是在数据库中，冗余的数据带会放大变更所带来数据更新量，这会给我们恐惧。我们希望数据结构可以如同OO的代码一样，随便更改不会带来问题。但是这是不可能的，OO中你可以根据需求来修改类型，因为你的对象都存在于内存中，一关闭什么都没了。但是在数据库中你必须面对那些历史遗留的数据，在追求完美的程序员看来，这些数据如同腐败变质的东西一样恶心。所以在潜意识中，他们不能接受这种垃圾数据继续存在的修改方式，无法接受“科技图书2”这样的类或者表，除非客户如同上述c情况那样，强行要求保留原有的数据，多数程序员不会容许原来的数据在世界上再多留一分钟。
带给我们恐惧的不是冗余，而是追求完美的执念。
兼容，协作，这是沉浸在自我设计中的程序员最容易忽略的问题。每个程序员都希望设计一个可以随便怎么改的结构，这是不现实的。但是如果你具备兼容和协作的思维，为何不将需求变更视为开发一个新的软件模块，兼容原有的功能和数据呢？