软件开发者喜欢重构代码。重构会很快(有时)，且当正确重构后，减少了代码量，还加快了应用的响应速度。DAB们也喜欢重构代码。当我们正确重构后，我们也可以获得一样的益处。另一方面，重构数据库架构，是一个要命的恶梦。

　　修改边缘代码很容易，但是从一张表里将100,000,000条记录及时地移动到另一张表中多少是有些难度。它将花费大量时间。

　　然而，因为这些年来，数据库通过发展，很多内容都改变了，而数据库也需要通过它们来改变。

　　一个我曾经为其工作过的客户(他们不愿意透露身份，但我希望他们知道自己是谁)有一个急切需要重构的数据库。在此数据库中，一张表中的键是一列，但另一张表通过两列的联合键来与前一张表的键来关联。他们还有数据类型是varchar的但存有数据类型的值的列，这是因为很久之前此列是保存varchar类型的值。他们在所有的存储过程和函数中使用ISNULL来约束空值，当应用逻辑不允许在列中有空值时(有时数据库列没有NOT NULL属性)，但是WHERE子句中的列名后边仍有ISNULL()函数。

　　我很久之前就给他们指出了此问题，但悲哀的是得到这样的回复：我们没有时间，而且没有足够的商业影响来证明花这些时间是值得的。这样的放，他们的服务器要花钱，且他们经常使服务器的运行状态达到饱和,没有增长的空间。要移动到更大的服务器上则需要从一个双核服务器移到四核服务器上。那将花费大量时间来迁移，每个月还要花钱来买SQL许可(它们由服务提供者管理)。那些成本将远比通过数据库重构将其设计为一个更为正常的数据库所花费的成本要多。

　　最糟糕的地方是他们明知道如果想保持业务增长,最终必将要这样做,但是他们就是不这样做。在此问题上，他们还是继续在硬件上花费越来越多的钱，而不是在恰当的地方使得投资最大化。

　　一直以来你都在躲避数据库重构,现在不要躲避了,开始做吧。最后你会发现它是值得的。假设你不会很快有新的硬件使用，但是在经济方面，我们都需要尽我们的职责来为公司省钱。这就是我们这些DBA们真正可以帮到忙的地方。