我与DBA讨论了如何更改数据库架构。他的观点是，所有变化都必须是可逆的。例如：
这种方法的好处是，如果（例如）发布失败并且需要恢复到应用程序的先前版本，则可以将数据库切换到先前版本。如果简单地删除表和列，这将无法实现。
我对这种方法的智慧有自己的看法，但我会暂时将它们留给自己，因为害怕偏见反应。如果它有所不同，环境是一个开发社交网络应用程序的初创公司。
答案 0 :(得分：4)
您没有说明您所处的软件环境，而是来自企业（银行）工作，这些是我的看法。
一般原则是正确的，发布可能不是SQL代码而是客户端代码可能会出错，您需要能够恢复服务器。我已经多次看到过这种情况。
如果在发布后的某个时间发现问题几个小时，那么您将不得不处理同时输入的任何数据。
可能是在发布时获取的数据库副本可能会使用新数据进行更新，但环境可能不允许这样做（尽管这是我完成大型发布的主要方式）。
根据我的经验，发布问题可能会影响系统的一小部分，而且大部分都是正常的，因此您不希望关闭并还原整个系统只是为了恢复小部分。
然而，鉴于这些变化需要是可逆的，我认为你的dba有点保守。
应该在某个阶段删除表和列，但这可能要等到以后的版本才能恢复
是的，总是复制数据（实际上最好不要重命名，除非名称完全不合适，做出改变的风险肯定会带来任何好处）。如果要更改列的类型，则取决于SQL Server以及正在执行的操作。对于Sybase的例子，我会允许增加列的大小，因为它不会改变数据，但是减小大小需要复制，因为数据值可能会受到影响。
至于存储过程和触发器，我不会重命名而只是覆盖，因为这就像编译代码一样。您正在更改的对象不依赖于数据，因此可以立即重新创建。虽然这确实假设你可以很容易地从版本控制等获得任何以前版本的存储过程。（我已经看到dbs代码不受版本控制，唯一的版本在db中，然后我可以看到不需要覆盖代码 - 但我会在下一个版本之前控制代码）
答案 1 :(得分：1)
我同意你应该总是备份你的数据库，但是你也不应该用无用的信息来污染你的数据库。同样你不应该用无用的代码来防止你的代码被污染。
备份数据库，然后制作你的mod。如果发生了什么事情，请恢复备份。
将所有内容保存在数据库中将导致令人难以置信的膨胀。不仅如此，您还会遇到一些性能问题。 最重要的是，后来没有人愿意接触它，因为他们不知道为什么会这样。与代码不同，在未来的某个日期，为什么在数据库中找出为什么会有其他列等更难。他们不会知道它的遗留数据/代码，因此他们会继续维护它！
答案 2 :(得分：1)
“过时的表/列不应该在它们变得多余时就被删除。相反，它们应该保留至少几个版本。”
那么他是否也会保留那些他不想立即放弃的那些列的约束？
意味着由于用户声明的约束不再是业务规则的一部分，可能会出现更新失败？
我对那些一直寻求“逐步和谨慎地逐步淘汰”的人表示同情。在你提到的所有例子中，我只是不知道这种方法在数据库环境中是否成立。
答案 3 :(得分：0)
这听起来像DBA懒得做备份。 ;）