我与我们的DBA讨论了如何更改数据库模式。他的观点是所有的变化都必须是可逆的。例如：向后兼容的数据库更改
这种方法的好处是，可以把数据库切换到以前的版本，如果（例如）发布失败，需要恢复到以前版本的应用程序。如果简单地删除表和列，这是不可能的。
我有我自己对这种做法是否明智的意见，但我会保持他们对自己暂时生怕偏置的答复。如果它有所不同，该环境是一家开发社交网络应用程序的创业公司。
你不说你在什么软件环境，但从企业（银行）工作这些是我的看法。
总的原则是正确的东西可以去错的释放也许不是SQL代码，但客户端代码，你将需要能够恢复服务器。我曾多次看到过这种情况。
如果发现问题发布后的一段时间说了几个小时，那么你将不得不面对在此期间输入的任何数据。
这可能是在释放时所采取的数据库的副本可以用新的数据更新，但环境可能不允许这样（虽然这是我做过大量释放的主要途径）。
以我的经验释放问题可能会影响到系统的一个小部分，大部分是OK，所以你不想关闭，只是恢复整个系统恢复一小部分。
但是，鉴于这些变化需要可逆，我认为你的dba有点保守。
表和列应在某个阶段被丢弃而是可以等到以后的版本，让你可以恢复
是始终将数据复制（实际上可能是最好不要改名为除非名称是完全不承担改变的风险肯定会使成本减少）。如果要更改列的类型，则取决于SQL Server以及正在执行的操作。对于Sybase来说，我会允许增加列的大小，因为它不会改变数据，但是减小大小需要复制，因为数据值可能会受到影响。
至于存储过程和触发器我不会做一个重命名和只是简单地覆盖，因为这是像编译代码。您正在改变的对象不依赖于数据，因此可以立即重新创建。虽然这确实假设你可以很容易地从版本控制等获得任何先前版本的存储过程（我已经看到dbs代码不在版本控制下，唯一的版本在db中，然后我可以看到不需要覆盖代码 - 但是我会在下一个版本之前控制代码）
这听起来像DBA懒得做备份。 ;）
仅备份不是一个完整的解决方案。如果在发布后的一段时间内发现问题，您将不得不处理在此期间输入的任何数据。 – 2009-09-24 15:54:33
这是一个非常苛刻的陈述，没有上下文。如果数据库很大或很多（或两者都有），备份和恢复不是快速操作。 – Joe 2009-09-24 16:50:13
对不起，错过了笑脸。 – 2009-09-25 07:07:44
我同意你应该总是备份你的数据库，但是你也不应该用无用的信息来污染你的数据库。就像你不应该让你的代码被无用的代码所污染一样。
备份数据库，然后制作你的MODS。如果发生什么情况，请恢复备份。
保持数据库中的所有内容始终会导致令人难以置信的膨胀。不仅如此，你可能会遇到一些性能问题。 最重要的是，后来没有人会想要触摸它，因为他们不知道为什么它在那里。与代码不同，要想知道为什么未来某个日期的数据库中还有额外的列等。他们不会知道它是传统的数据/代码，因此他们会继续维护它！
如果您在备份/恢复过程中可以承受系统停机，那么很好。 – Joe 2009-09-24 16:51:01
“过时的表/列不应该在它们变得多余时立即删除，而应该保留至少几个版本。”
然后他是否也保留那些他不想立即放弃的那些列的约束？
这意味着更新失败可能由于用户声明的约束不再是业务规则的一部分而出现？
我对那些一直试图“逐步和谨慎逐步淘汰”的人表示同情。我只是不知道在你提到的所有例子中，这种方法在数据库环境中是否成立。
我已添加环境详细信息 – 2009-09-24 16:07:48