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