sql - 数据库修改脚本 - 推出/回滚最佳实践？

Question

我正在寻找有关数据库脚本修改的最佳实践的见解，这些修改与软件系统的其他代码更改一起进行。

我曾经在一家公司工作，该公司坚持每次推出都要准备好回滚，以防出现问题。这听起来很合理，但在我看来，通过脚本部署的数据库修改的回滚代码与推出脚本一样有可能失败。

对于托管代码，版本控制使这变得非常简单，但对于数据库架构，回滚更改并不那么容易 - 特别是如果数据在推出过程中发生更改。

我目前的做法是通过在后期开发期间针对测试数据库运行来测试推出代码，然后针对该测试数据库运行应用程序。在此之后，我备份实时数据库，并继续推出。

我还没有遇到问题，但我想知道其他商店如何管理数据库更改，以及从任何错误中恢复的策略是什么。

Answer 1

我们所有的数据库脚本都针对类似于我们的实时数据库的数据库进行了几个测试阶段。这样我们就可以相当确定修改脚本将按预期工作。

对于回滚，存储过程、 View 、函数、触发器，所有编程的东西都很容易回滚，只需应用对象的先前版本即可。

正如您提到的，具有挑战性的部分出现在从表中更新/删除记录，甚至向表中添加新列时。你是对的，在这种情况下，回滚很可能会失败。

我们所做的是，如果我们有一个不能轻易回滚的更改，但它是一个敏感/关键部分...我们有一组回滚脚本，这些脚本也经过相同的测试环境。我们运行更新脚本，验证它是否按预期工作，然后运行回滚脚本，并验证它是否像修改前一样工作。

作为预防措施，我们所做的另一件事是在更新之前创建数据库快照 (SQL Server 2005)。这样，如果出现任何意外问题，我们可以使用快照来恢复更新期间可能丢失的任何数据。

因此，最安全的做法是针对尽可能接近您的实时系统的数据库进行测试，并测试您的回滚脚本......以防万一这两个都失败了，准备好快照以备不时之需。