asp.net - SQL Server 2008 架构更改的最佳实践

Question

我正在寻找有关以下内容的信息:

将开发数据库的架构更新到生产数据库的最佳实践是什么，或者更简洁地进行一般数据库架构更改。

生产数据库是两个不同 ASP.NET 网站的后端。

我们的架构更改过程相当稳健，每个“迁移”实际上都是包含架构更改的 .cs 文件。然后，我们将使用 ADO.NET 对数据库应用架构更改。

我的问题更多是关于数据库的连接性。

我应该停止正在访问数据库的两个网站吗？我想我应该这么做。我应该将数据库置于单用户模式吗？看起来我应该这样做，但我对此并不完全有信心。

我可能会错过什么？在涉及数据库架构更改之前，有哪些事情让您感到困扰。

Answer 1

如果更新更改了列名称、存储过程参数等内容，则在进行架构更新之前始终使应用程序离线。

如果更新只是为了不影响数据正常处理的事情，那么您可能可以“热”地进行更新。此类别适用于您添加索引、表等内容的情况。

如果有人在处理架构更新时使用该应用程序，您很可能会发现自己处于数据一致性受损的情况。

如果此更新需要对您的 Web 应用程序文件进行相应的更新，请在执行更新之前使站点脱机。您不知道谁可能正在查看某个页面并单击“提交”却收到错误...

此类维护通常是在非高峰时段进行。您需要提前通知用户网站何时关闭以及关闭多长时间。

此外，我们还使用 Redgate 的 SQL Compare 等工具来编写数据库更新脚本。这是在实际推送之前从生产数据刷新的临时服务器上进行的，以确保不会出现意外并且可以非常快速地完成。

关于单用户模式，您通常使用此模式将对数据库的访问限制为单个 Management Studio 实例。这不是我们在部署过程中通常会做的事情。