使用 SQL Server 部署数据库更改的简单方法是什么？

题

我从事的软件系统是一个医疗计费系统，大量的数据和数据表，以及存储过程。

我正在读这篇文章“改善代码的 12 个步骤”并且在《乔尔测试 #2》中指出：你能一步完成构建吗？

现在我想知道，这是否意味着部署构建（以便客户可以更新其部署）。

现在我遇到的主要问题是如何进行一步数据库更新？

目前，当我们对数据库进行更改时，所有更改都会被记录并添加到数据库更新脚本中，该脚本会在创建部署到客户构建时附加一个版本号。

有没有更简单的方法来做到这一点？像我提到的那样，某些脚本或应用程序会“前后”查看数据库模式并创建更新脚本？

或者这只是每个人都这样做的方式，我觉得很难相信，但却是合理的。

自动化系统可以减少错误，并大大加快部署构建时间，我有兴趣知道如何做到这一点。

解决方案

您可以经历不同级别的复杂性：

如果您有手动创建的更新脚本，并且只是寻找一种将这些脚本轻松应用到各种服务器的方法，请查看 SSW SQL 部署由 SSW 咨询公司提供。它可以很好地处理这种情况
如果您倾向于执行更多数据库差异方法，那么 Red Gate 的 SQL比较（已经提到过）和 SQL打包器创造一个伟大的组合。您可以区分新旧数据库，然后将更改应用到一个不错的包中 - 作为 EXE 或 C# 项目
如果您想要一种真正的、端到端的、经过深思熟虑的方法（有一点学习曲线），请查看 Innovartis 的 DBGhost 方法。这是如何处理数据库开发和增量更新的完整方法/技术。它非常强大并且看起来非常有前途 - 但这是一种全有或全无的方法：要么你购买它并端到端地使用它，要么你不购买它

希望这个对你有帮助！

其他提示

展鹏具有工具 SQL比较来比较数据库和生成脚本同步。我们习惯使用它，但最近使用你所描述的相同的过程切换到手动脚本。使用手动，细粒，具有独特的版本号脚本已制定了良好。

我们有我们的升级脚本集成到单元测试，所以他们得到的代码一起测试作为持续集成的一部分。我认为这是一个重要组成部分“在一个步骤中制备的构建。”

看看这个博客帖子。我从一对夫妇项目的任何DB版本使用的这种类型的单个更新脚本，它工作得很好。

您可能需要调整工作流程中的位，以适应您的工作流程和/或更新模板.sql文件，但总体来说我发现这个想法是一个非常坚实的方式来部署DB

编辑：只是为了阐述了我如何使用这种技术。基本上，所有我的数据库修改脚本得到付诸源控制。然后，在构建箱后生成步骤，这曼波工具运行的脚本目录以脚本擀成一个事务包含允许回滚如果有什么歪一个脚本。然后，安装程序是足够聪明去寻找的.sql脚本对现有的数据库上运行。

此工作的原因是因为所述卷起脚本检查以查看每一块中，这里是单个脚本已经运行针对所需的数据库。其结果是，只有最新的脚本得到执行。一个警告的情况是，一旦一个脚本签入源代码控制，并已部署的，你不能因为跟踪表已经认为脚本已运行编辑。这是罚款，我就因为我们只需要添加另一个脚本的脚本文件夹中工作的项目。

希望我在讲解过程中也有足够的了解。这真的没有那么复杂，如果方法适用于你的项目是非常有用的。

回答了第一个问题：“现在我想知道，这是否意味着部署版本（让客户能够更新他们的部署）？”

我相信乔尔测试＃2是不是部署移动到督促，但在开发过程中continuios融合。

至于在PROD数据库的变化，它们应该通过脚本完成的事务部署的一部分，或者数据库已备份之后。你总是希望能够导航回应该事在部署失败。

建立数据库作为一组依赖于海誓山盟补丁。然后使用如 https://github.com/LuvDaSun/sqlpatch 工具（由我）建立一个SQL文件以进行部署。

sqlpatch将在正确的顺序排序的修补程序和每个补丁只执行一次确认，即使同一脚本运行两次。

此策略可用于在CI / CD环境数据库的部署。这使部署作为推到分支一样简单。

有是同步数据库的应用程序，但我觉得你最好做你正在做的事情。编写一个脚本来更新数据库使您能够处理错误和运行事务的能力。这被认为是最佳实践。

微软本身引入数据层应用在SQL 2012 的作为自由选择用于部署和升级数据库。

余使用和这样的工具，包括用于生产部署。

许可以下： CC-BY-SA 和归因