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

发布时间：2020-12-16 07:15:49 所属栏目：asp.Net 来源：网络整理

导读：我正在寻找有关以下内容的信息：将我的开发者数据库的模式更新到生产数据库的最佳实践是什么,或者甚至更简洁地进行数据库模式更改. 生产数据库是两个不同的ASP.NET网站的后端. 我们的架构更改过程非常强大,每个“迁移”实际上都是包含架构更改的.cs文件.然

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

将我的开发者数据库的模式更新到生产数据库的最佳实践是什么,或者甚至更简洁地进行数据库模式更改.

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

我们的架构更改过程非常强大,每个“迁移”实际上都是包含架构更改的.cs文件.然后,我们将使用ADO.NET对数据库应用模式更改.

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

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

我能错过什么？在涉及数据库架构更改之前,有什么东西在手中咬了你.

如果更新更改了列名,存储过程参数等内容,则在执行模式更新之前始终使应用程序脱机.

如果更新仅适用于不影响数据正常处理的事情,那么您可能会“热”.此类别是在添加索引,表格等内容时.

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

如果此更新需要对Web应用程序文件进行相应更新,请在执行更新之前使站点脱机.您不知道谁可能正在查看页面,并且仅为了获取错误而点击提交…

通常,此类维护是在非高峰时段完成的.您需要提前通知用户网站何时停机以及停机时间.

此外,我们使用Redgate的SQL Compare等工具编写我们的数据库更新脚本.这是在实际推送之前已从生产数据刷新的登台服务器上实现的,以确保没有意外,并且可以非常快速地完成.

关于单用户模式,通常使用此方法将数据库访问限制为单个管理工作室实例.这不是我们通常在部署过程中所做的事情.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!