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