彩票走势图

SQL Compare使用教程:数据库开发阶段(一)

翻译|使用教程|编辑:杨鹏连|2020-07-08 11:01:08.437|阅读 185 次

概述:本文介绍了所有这些任务,并演示了使用SQL Compare可以实现的功能。在随后的文章中,我将显示任务槽到自动SQL Change Automation过程中。

# 慧都年终大促·界面/图表报表/文档/IDE等千款热门软控件火热促销中 >>

SQL Compare是一款比较和同步SQL Server数据库结构的工具。现有超过150,000的数据库管理员、开发人员和测试人员在使用它。当测试本地数据库,暂存或激活远程服务器的数据库时,SQL Compare将分配数据库的过程自动化。

点击下载SQL Compare试用版

数据库开发永远不会是一个容易的过程,但是如果给数据库指定版本号,那么很多人的工作就会变得更轻松,您可以通过一种简单的方法来验证是否始终可以构建数据库以及每个版本的来源源代码中保留了将迁移脚本从上一个版本迁移到下一个版本的功能。开发工作是一个团队过程,所有内容都必须可见且可重复。

数据库版本和版本管理

无论以何种方式完成数据库的开发工作,开发团队都将在某个时候确定发布该数据库的版本。此版本将由版本控制中的脚本表示。经过适当的单元和集成测试后,数据库的版本将成为候选版本。为什么使用“候选人”一词?因为它可能无法通过部署管道一直到生产的一个或多个后续测试或检查。

一旦某个版本成为发行候选版本,就必须保护它不受任何修改,否则后续测试将无效。任何自动化的DevOps流程都需要能够检查其是否使用了正确的未更改版本。该版本在数据库中的明显位置是将其作为扩展属性附加到数据库。最好根据源代码管理或NuGet包中版本的副本进行检查。

那么,这些DevOps流程是什么?一旦开发数据库构建成为候选版本,它将进入通常称为“部署管道”的过程。这是一个错误的称呼,因为它意味着每次检查都必须顺序进行。实际上,最好并行进行。必须以多种方式测试候选发布版,以确保其足够健壮,合法,能够满足客户的期望以及满足客户的需求。除了通常对每个构建进行的单元和集成测试之外,检查所有这些内容还涉及非常不同的测试范围。完成所有这些检查之后,数据库就可以进行登台了。如果它可以分阶段通过所有测试,那是可以合法测试真实数据的少数几个地方之一,那么就可以放心地将其发布到生产环境中。

从我所说的内容中,您会注意到,如果不进行仔细的管理,此发布过程可能会变成“痛苦的世界”。许多数据库需要与候选版本相同。测试单元还可以包括数据库的先前版本。我经历过开发站点,这些站点有多个版本,而其他地方根本不存在。

您已经进行了用户验收测试,不仅必须存在运行数据库及其关联的应用程序,而且还要协调所有工作并以正确的版本进行操作。然后是暂存,在此您再次需要当前的暂存数据库服务器来将候选发布以及生产数据放置到位。如果此过程中涉及的任何数据库版本都不正确,则发布过程将失败,因为无法进行一项或多项要求的检查,或者更糟的是,对于错误的版本进行了检查。

在开发中,您需要掌握数据才能快速工作,而部署中则是另一回事。您可以构建一个dev数据库并复制所需的任何数据,但是测试数据库或UAT数据库将需要精心策划的数据。要更新或回滚这样的数据库,您需要一个迁移脚本。每个新发行版都需要一个迁移脚本,该脚本会将先前发行的版本更改为新发行版。因为它仅对目标数据库的特定版本有效,所以它需要检查目标的版本并仅在目标版本正确时运行。这是发行版所需的唯一迁移脚本,尽管俗世也将添加反方向运行的回滚脚本。

使用SQL Compare的迁移脚本作为起点

创建一个有效的脚本来在版本之间迁移数据库应该是一个简单的过程,但是不要指望它。候选发布版本将与生产版本有所不同。如果您已经重新设计了表结构,或者重命名了许多例程,列或表,那么您的模式比较工具可能无法始终如您所愿地工作。它将需要帮助来保存现有数据。如果不能,它可能会通知您,但可能不会。

那你该怎么办 第一个本能是手工剪切迁移脚本。我退缩了,只是在想,因为细节很重要,恶魔潜伏在那里。忘记所有与大型变更同时进行的细微变更非常容易,您要么过分乐观,部署失败,要么被困在几乎无法修改的修改-测试-修改-测试周期中确保迁移脚本有效。我的首选是建立并修改自动生成的迁移脚本,该脚本是模式比较的输出,由SQL Compare完成。这是因为SQL Compare(通过检查它生成的脚本会注意到)能够进行许多巧妙的迁移,而简单的手工剪切ALTER脚本会失败。

尽管迁移脚本是您在部署管道中使用的脚本,但重要的是不要在开发过程中因迁移问题而过于分散注意力。数据库开发人员应该能够进行很多逐步改进,甚至沉迷于实验,而不必担心下游麻烦。您可以将所有次要内容委托给构建过程。即使当您从根本上更改表时,SQL Compare有时有时无法介意您的意图,它仍然会占用所有较小的内容。您需要做的就是添加棘手的迁移代码,该代码很可能已经被开发人员剪切和测试,作为特定的迁移脚本。毕竟,开发人员无论如何都必须这样做以修改其测试数据,以准备在开发过程中测试每个新版本的构建。

您需要了解的一些SQL比较约定

SQL Compare自动生成一个迁移脚本,该脚本将使目标数据库的架构与源数据库的架构匹配。它旨在确保此脚本成功完成或回滚,不留下任何痕迹。为此,它会在每个DDL语句(例如或)之后检查错误级别CREATE,并且如果发生了不会导致脚本立即回滚或终止的错误,它将设置连接状态,直到该操作不再执行。最终使用。例如:ALTERGRANTIF @@ERROR <> 0 SET NOEXEC ON

RINT N'Altering [dbo].[byroyalty]'
GO
ALTER PROCEDURE [dbo].[byroyalty] @percentage int
AS
select au_id from titleauthor
where titleauthor.royaltyper = @percentage
GO
IF @@ERROR <> 0 SET NOEXEC ON
GO

脚本末尾有非常重要的批处理,可以捕获任何错误。

DECLARE @Success AS BIT
SET @Success = 1
SET NOEXEC OFF
IF (@Success = 1) PRINT 'The database update succeeded'
ELSE BEGIN
    IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION
    PRINT 'The database update failed'
END

如果此时SQL Server仍在执行代码,它将声明一个名为的变量@success并将其设置为true。然后,它将设置连接以执行代码,而不管是否存在错误。如果将变量成功设置为true,则迁移脚本被视为成功。否则,任何事务都会回滚,并且更新失败。

要成为一个体贴的参与者,在适应此脚本时,您将需要在每个DDL SQL语句之后检查错误变量,并设置NOEXEC ON是否存在会影响迁移的错误。切勿NOEXEC OFF在更改SQL比较脚本时在使用的代码中进行设置!

在数据库上标记版本

“版本化”数据库的唯一确定方法是通过扩展属性在数据库上标记版本。尚无确定的标准。在准备第一个定制SQL Compare脚本的示例时,让我们获得一种就地对数据库进行版本控制的简单方法。稍后,这将使我们能够适当地使用迁移脚本,而无需进行详尽的检查。

这是一些代码,可让您在数据库(在本例中为Pubs数据库)中设置版本号。

SET NOEXEC off
go
USE pubs
DECLARE @DatabaseInfo NVARCHAR(3750), @version NVARCHAR(20)
SET @version=N'2.1.5'
SELECT @DatabaseInfo =
  (
  SELECT 'Pubs' AS "Name", @version  AS "Version",
  'The Pubs (publishing) Database supports a fictitious bookshop.' AS "Description",
    GetDate() AS "Modified",
SUser_Name() AS "by"
  FOR JSON PATH
  );
 
IF not EXISTS
  (SELECT name, value  FROM fn_listextendedproperty(
     N'Database_Info',default, default, default, default, default, default) )
    EXEC sys.sp_addextendedproperty @name=N'Database_Info', @value=@DatabaseInfo
ELSE
  EXEC sys.sp_Updateextendedproperty  @name=N'Database_Info', @value=@DatabaseInfo

创建Database_Info扩展属性后,我们现在可以使用版本标记原始数据库。在开发数据库的新版本时,我们可以很简单地将相同版本的图章和更新的版本号放在同一位置。如果在事务中完成,它将在成功迁移后自动复制到目标。

在GitHub中,在提交源代码之前,我们可以在version.json文件中维护数据库的版本号,并将其设置为正确的版本号。该版本号将不在对象级源中,因为它是数据库本身的属性。但是,如果您使用实时数据库作为源,它将在迁移脚本中。上面的代码在Github中为AddInitialVersion.sql。

建立实践实验室

为了进行简单的演示,我们将从好奇的柜子中取出古老的pubs数据库,并将其安装为“假装”生产服务器。我们将创建一个Github项目,其目的是使数据库更新一些。

我们会假装我们的Pubs数据库的“生产”副本(当前版本)的版本为2.1.5,因此将其标记为该版本。这是一个只读参考数据库,可用作测试数据的源,并用于在开发过程中运行测试时检查数据是否未更改。pubs的备份在这里。

要在其上标记版本,可以使用此方法,它假定Database_Info扩展属性尚不存在。

EXEC sp_addextendedproperty N'Database_Info',
    N'[{"Name":"Pubs","Version":"2.1.5","Description":"The Pubs (publishing) Database supports a fictitious bookshop.","Modified":"2020-05-06T13:57:56.217","by":"PhilFactor"}]',
    NULL, NULL, NULL, NULL, NULL, NULL;

为了模拟开发过程,我们将在开发服务器上安装原始Pubs数据库的另一个副本,并在生产中使用当前 版本。这表示起始版本,即您要更改以创建新版本的版本。通过引用当前版本(以及当前发行版),您可以随时了解迁移脚本需要实现的目标。对于某些团队来说,这可能是一个共享的开发数据库。

相关产品推荐:

SQL Prompt:SQL语法提示工具

SQL Toolbelt:Red Gate产品套包

SQL Monitor:SQL Server监控工具


想要购买SQL Compare正版授权,或了解更多产品信息请点击


标签:

本站文章除注明转载外,均为本站原创或翻译。欢迎任何形式的转载,但请务必注明出处、不得修改原文相关链接,如果存在内容上的异议请邮件反馈至chenjj@pclwef.cn

文章转载自:

为你推荐

  • 推荐视频
  • 推荐活动
  • 推荐产品
  • 推荐文章
  • 慧都慧问
扫码咨询


添加微信 立即咨询

电话咨询

客服热线
023-68661681

TOP