SQL Server 2008 架构更改的最佳实践

Posted 2023-03-14

【中文标题】SQL Server 2008 架构更改的最佳实践

【英文标题】：Best practice for SQL Server 2008 schema change

【发布时间】：2011-05-24 20:13:51

【问题描述】：

我正在寻找有关以下方面的信息：

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

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

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

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

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

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

【参考方案1】：

理想情况，但并非总是可以实现：您进行的架构更改与您网站的 V 版本兼容。然后您将 V 发布到您的 Web 服务器。一旦您的所有 Web 服务器都达到 V，您就可以执行任何清理（填充缺失值等），然后进行适当的可空性更改。

【参考方案2】：

我没有考虑使用 .cs/ado.net 路由来进行架构更改。我们所做的是创建 'delta' .SQL 文件 - SQL 来进行更改。这些是针对已知修订的架构执行的以进行更改，并且运行 .SQL 是部署的一部分。

尽我们所能，我们还尝试通过检查架构中的特定内容（例如列、索引等）的存在来确保它们多次安全运行。这样它们就可以“意外”多次执行。

当我们部署时，我们有一天/一周的特定时间，警告用户/客户，关闭网站等。在发布前的最后几天，几乎每天都在开发和暂存服务器上进行“实践”部署，最终部署的信心很高。

在 SQL 中保留架构更改，它们看起来更像是他们修改的“主”架构 SQL，因此更容易跟踪。调试也更少！

它们也与其他代码一起在 TFS 中进行管理。

【讨论】：

切向，关于多次执行是否安全：此属性称为幂等性。您的 .SQL 文件是幂等的。

【参考方案3】：

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

如果更新只是针对不影响数据正常处理的事情，那么您可能可以“热”地这样做。此类别适用于您添加索引、表格等内容时。

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

如果此更新需要对您的 Web 应用程序文件进行相应更新，请在执行更新之前使站点脱机。你不知道谁可能正在查看一个页面并准备点击提交，结果却报错...

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

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

关于单用户模式，您通常使用它来限制对单个管理工作室实例的数据库访问。作为部署的一部分，我们通常不会这样做。