我正在寻找有关数据库脚本的最佳实践的深入见解，以及与软件系统的其他代码更改相关的修改。
我曾经为一家公司工作，该公司坚持认为每一次推出都会在发生问题时准备就绪。这听起来很合理，但在我看来，通过脚本部署的数据库修改的回滚代码与推出脚本一样可能会失败。
对于托管代码，版本控制使这非常简单，但对于数据库模式，回滚更改并不容易 - 尤其是在数据作为推出的一部分进行更改时。
我目前的做法是通过在后期开发期间针对测试数据库运行来测试推出代码，然后针对该测试数据库运行应用程序。在此之后，我备份了实时数据库，然后继续推出。
我还没遇到问题，但我想知道其他商店如何管理数据库更改，以及从任何错误中恢复的策略。
答案 0 :(得分：2)
我们所有的数据库脚本都经过几个测试阶段，针对的数据库就像我们的实时数据库一样。通过这种方式，我们可以确定修改脚本将按预期工作。
对于回滚，存储过程，视图，函数，触发器，所有程序化都很容易回滚，只需应用以前版本的对象即可。
正如您所提到的，在更新/删除表中的记录，甚至向表中添加新列时，都会遇到挑战。你是对的，在这种情况下，回滚可能会失败。
我们所做的是，如果我们有一个无法轻松回滚的变更，但它是一个敏感/关键部分......我们有一套设置的回滚脚本也会经历相同的测试环境。我们运行更新脚本，验证它是否按预期工作，然后运行回滚脚本，并验证它是否像修改前一样工作。
我们做的另一件事只是预防措施是在更新之前创建数据库快照（SQL Server 2005）。这样，如果出现任何意外问题，我们可以使用快照来恢复在更新期间可能丢失的任何数据。
所以最安全的做法是对尽可能接近你的实时系统的数据库进行测试，并测试你的回滚脚本......以防万一这两个失败，准备好快照万一你需要它。
答案 1 :(得分：1)
SQL Diff（或类似的东西，如果您使用的是测试数据库，它总是有用的。它有很多检查和平衡，安全措施，以及在出现问题时恢复或回滚的方法。非常有用。