我正在寻找有关以下方面的信息：
将开发数据库的架构更新到生产数据库的最佳实践是什么，或者更简洁地进行一般的数据库架构更改。
生产数据库是两个不同 ASP.NET 网站的后端。
我们的架构更改过程相当稳健，每个“迁移”实际上都是一个包含架构更改的 .cs 文件。然后，我们将使用 ADO.NET 对 db 应用架构更改。
我的问题更多是关于数据库的连接性。
我应该停止访问数据库的两个网站吗？我想我应该。 我是否应该将数据库置于单用户模式。看起来我应该这样做，但我对此并不完全有信心。
我会错过什么？在数据库架构更改之前，有哪些事情让您感到困扰。
【问题讨论】：
标签： asp.net sql-server sql-server-2008 database-schema database-migration
理想情况，但并非总是可以实现：您进行的架构更改与您网站的 V
【讨论】：
我没有考虑使用 .cs/ado.net 路由来进行架构更改。我们所做的是创建 'delta' .SQL 文件 - SQL 来进行更改。这些是针对已知修订的架构执行的以进行更改，并且运行 .SQL 是部署的一部分。
尽我们所能，我们还尝试通过检查架构中的特定内容（例如列、索引等）的存在来确保它们多次安全运行。这样它们就可以“意外”多次执行。
当我们部署时，我们有一天/一周的特定时间，警告用户/客户，关闭网站等。在发布前的最后几天，几乎每天都在开发和暂存服务器上进行“实践”部署，最终部署的信心很高。
在 SQL 中保留架构更改，它们看起来更像是他们修改的“主”架构 SQL，因此更容易跟踪。调试也更少！
它们也与其他代码一起在 TFS 中进行管理。
【讨论】：
如果更新更改了列名、存储的过程参数等内容，则始终在进行架构更新之前使应用脱机。
如果更新只是针对不影响数据正常处理的事情，那么您可能可以“热”地这样做。此类别适用于您添加索引、表格等内容时。
如果有人在处理架构更新时使用该应用程序，您很可能会发现自己处于数据一致性受损的情况。
如果此更新需要对您的 Web 应用程序文件进行相应更新，请在执行更新之前使站点脱机。你不知道谁可能正在查看一个页面并准备点击提交，结果却报错...
此类维护通常在您的非高峰时段进行。您需要提前通知用户站点何时关闭以及关闭多长时间。
此外，我们使用 Redgate 的 SQL Compare 等工具来编写数据库更新脚本。这是在实际推送之前从生产数据刷新的登台服务器上进行的，以确保没有意外并且可以非常快速地完成。
关于单用户模式，您通常使用它来限制对单个管理工作室实例的数据库访问。作为部署的一部分，我们通常不会这样做。
【讨论】：