您当前的位置:
设计变更中的数据库表字段变更，一般怎么处理。
客制化软件。随着业务的变更，数据库表设计也需要相应变更，以往的某些数据表字段不用了可以删除吗？表、字段命名改变了，则代码中的处理要跟着调整，很麻烦，有没有什么好的办法减少这样的麻烦？
有时一对某一个版本的升版，数据库的变化只能加字段，不能删除和更改字段，数据表变得越来越臃肿，怎么办？
有没有对数据库表的改动，尽可以少影响代码的修的办法？
------解决方案--------------------
首先要说明，任何原则都不是教条。但是原则也是原则。
对于你的问题：
1. 基本上，刚刚在做的东西，是肯定会经常改来改去的。但是如果超过了3天（或者是1天），就不应该改了。往往是持着“容忍”的态度，而不是成事不足败事有余的“洁癖”态度而改来改去的。
2. 下决心解决麻烦，是要有真正的实力作保证的。例如我在50万行代码里要改变几个实体命令，那么就要保证一个人、30分钟，可以解决一两百个编译bug。然后当天还是能正常地发布产品版本。这里保证产品质量靠的是技术上的自动测试手段，可不是单纯什么“批评、给压力、求别动代码”之类的行政做法。
3. 站在编程角度上的所谓技术，跟站在设计角度上的技术比起来，实在是太低了。任何产品都要有一个设计过程，设计完毕、再实施和使用过程中还会有不断地进行架构重构的过程。因此这中间也有软件工程技术。所谓的“只能加字段”纠结于的那个层次，是谁造成的“只能”这样？
4. 真正的ORM，告诉你根本不用DBA，也不用程序员自己去整一大堆什么手工操作。如果你对ORM觉得太抽象，那么就使用 NoSql 吧。告别关系数据库的开发模式。
------解决方案--------------------
并且这3天（或者1）天做什么，也是要有讲究的。编程不是什么高尚的事情，编程不过是为了让测试通过而已。在你编程之前，你要进行高级别的设计工作，要想通一些事情，要写出必要的文档（测试程序也是一种文档，它非常精炼，而且是可执行的文档），甚至要拿到几十个人的团队面前讨论，然后才开发。
因此设计很重要，但是它不是“轻飘飘”的什么需求描述，而是实际上能够落实到你1天、甚至1小时的编程内容的那些设计。做好这些设计，而不是先动手写实现代码，你就可以避免像个无头苍蝇般地胡乱写出什么数据库表表结构来。
------解决方案--------------------
关系版本升级肯定是可以“删除”字段的，只不过不如增加字段和增加新的表出现的概率多。
假设要把数据库设计版本从199版升级到215版，你肯定要连续运行200、201、201....215版的升级程序，决不能“一步到位”地升级到215版。
而这个升级过程中，不仅仅可能删除字段、索引之类的，而且可能会对数据进行整理（例如补充一些数据的快速参考数据）。但是对数据的整理，往往也可以在应用程序中通过业务逻辑的兼容性来实现（至少是在最近几个月的业务逻辑代码中会出现这种兼容性代码）。因此为什么会有灵活性？其实你需要先进性成千上万次地自动测试，而你产品质量很高的情况下，你就不会纠结于“非得这样改数据库表！非得那样改程序业务适配性！”之类的东西。小的改动，往往只是一种持续一、两天的“麻烦”的体验，但是绝对不会超过3天。
反之，如果感觉总是想抄袭别人一大帮人都说的那种做法，甚至即使自己做了以后还是要整天纠结，就是你的实践上的问题，而不是理论的问题。
因此这类问题不是理论，没有想当然的“净室”或者“银弹”。
------解决方案--------------------
http://zh.wikipedia.org/wiki/DevOps