Visual Studio进行SQL Server源代码管理和部署方法

编写一次性脚本

编写一次性脚本并不容易。首先，SSDT中并没有一次性脚本的概念，因为它不并清楚某段脚本是否曾经运行过，因此你所能做的就是尽量用if语句覆盖你的脚本，以此进行判断。

处理一次性脚本的另一种方法是手动修改部署脚本，这种方式具有高度灵活性，但却是不可重复的，你必须对每个环境重新应用所有的改动。

加载表数据的模式

SSDT中所缺少的另一项特性是表的加载，理想的情况下，所有的查找表数据都应该保存在源代码控制中，如同其它数据库对象一样。但由于这一特性的缺乏，我们不得不通过其它替代途径实现这一功能。

其中一种途径是使用MERGE语句。首先，为你的目标表创建一个结构类似的临时表，随后在该临时表中加入你所需的数据。随后你就可以使用MERGE语句执行必要的插入、更新和删除操作。

另外一种途径是编写一个插入或更新的存储过程，然后就可以通过调用该存储过程对目标表中的每一行进行操作了。这种方法允许你处理复杂的逻辑，但无法通过这种方式删除过期的数据。

连接数据库

对于大型系统来说，仅仅使用schema作为命名空间往往是不够的。出于多种不同的原因，例如部署周期、安全性、性能和灾备，往往会将对象分布在多个数据库、乃至多台服务器上。

只要你对这些情况做好计划，SSDT都能够处理。你需要注意的一点是循环引用的限制，某个由SSDT管理的数据库可以对另一个数据库进行引用，哪怕后者处于不同的服务器上，只要你能够建立一个清晰的编译顺序就可以实现这一点。这种情形和.net项目的引用是完全一样的。

一种常见的情形是，某个新建的数据库需要引用某个遗留系统的数据库。首先要为旧数据库创建脚本，并将其导入到一个空的项目中。你并不需要使用SQL Server Data Tools管理这个遗留数据库，只需要它所对应的元数据就可以了。如果需要，你也可以仅仅导入那些新数据库所依赖的对象。

接下来你需要添加一个数据库引用，在这里你需要做出一个重要的决定，是否让旧的数据库也驻留在同一台服务器上。虽然你也可以事后改变想法，但过程既麻烦又容易出错。以下是添加引用的对话框：

其中的数据库变量以及可选的服务器变量会对你的自定义函数及存储过程的实际名称产生影响，因此请确保你使用了[$(variable)]这一模式，否则你可能会遇到编译错误。当你实际发布时，系统会要求你为这些变量填入实际名称。

当你按下“加载值”按钮时，在项目级别所定义的默认值将作为实际的值填入这些变量中。为了在今后的部署中节约时间，你也可以将这些数值保存为发布档案的一部分。

SQL CLR

虽然在SQL Server中使用C#代码的做法曾经一度遭受一些非议，但在某些情况下还是非常有用的。在某些场合中，由JIT编译的.NET代码比起解释型的T-SQL会得到更好的性能。而对于某些数据类型来说，例如几何数据与地理位置，你完全没有其它选择。

使用SQL CLR的一个主要问题在于部署。通常来说，要将一个.NET程序集部署到SQL Server中，需要手动将DLL拷贝到某处，随后一个一个地进行手动添加。SSDT的发布工具能够消除这一问题，它会将程序集进行编码成为一个SQL语句，与部署脚本的其余部分进行内联。

外部项目与程序集

按照约定，加入SSDT项目的程序集会首先添加到一个名为“Assemblies”的文件夹中。虽然这并非必须，但它会使得对DLL的管理更加容易。如果你决定遵循这一建议，请首先完成这一步骤。

接下来，你可以通过常用的.NET“添加引用”对话框添加对某个项目或是程序集的引用。

最后一步是将你需要在SQL中使用的类型与函数暴露出来，你可以在“添加项目”对话框中的SQL CLR文件夹选项中找到对应的模板。这种做法与手动注册SQL CLR类型和函数没有分别。

内部项目

内部项目是指驻留在数据库项目中的某个C#项目，它将随着数据库自动构建及部署，因此你不必担心对引用及程序集的管理。虽然你无法实现CLR版本的静态代码分析功能，但除此之外它的行为与其它C#项目相比完全一致。

内部项目的一个有用的特性在于，你不需要显式地通过SQL注册函数。编译器看到SqlFunction属性之后，会自动在项目定义的默认命名空间中创建正确的SQL原型。

重编译问题

当你应用CLR项目时，无论是内部项目还是外部项目，重编译都会成为问题。尤其是当你在某个计算字段中使用了某个SQL CLR函数的时候。

本质上，问题在于Visual Studio会经常对C#项目进行重编译，哪怕没有任何改变。由于新的版本中使用了一个新的hash码，发布工具就会认为该项目是个新的版本，并且重新部署整个程序集。在之前所提到的计算字段的场景中，发布工具就需要对受影响的表中的每一行进行重新计算。

当这个问题出现时，可以将SQL CLR代码迁移到某个外部项目中，随后将编译后的项目程序集放到Assemblies文件夹中，就所同一个第三方类库一样。要注意的是这种方式有一个风险，那就是你很可能在进行变更的时候忘了更新该程序集。

全文索引

SQL Server Data Tools对全文索引仅提供了部分支持，它对于创建与管理全文索引目录提供了良好的支持，你也可以将FTS索引添加到任何需要使用它的表中。你可能遇到的问题在于，SSDT仅支持空的非索引字表（StopList），这是因为非索引字表中的内容被视为数据，而不是schema，因此SSDT不知道如何将它的内容保持更新。

有一个应对该问题的临时方案，就是使用部署后脚本加载其中的数据，正如同对于查找表数据的处理方式一样。一旦创建了非索引字表之后，发布工具将不会再修改其中的数据。

版本号

SQL Server本身对于版本号并没有一个强烈的概念。在理论上，你可以在某个编译后数据层的应用（dacpac）中加入版本号，但这种方式在实践中是难以运行的。目前并没有一种非常良好的方式能够获取到这个值，你只能选择在构建后脚本中对dacpac版本进行自动增值处理。

你可以考虑采取这种方式：创建一个内部项目，其中只包含一个名为dbo.GetDatabaseVersion的函数，该函数能够从C#程序集中读取版本号。如果你在程序集版本中使用了通配符，版本号就能够自动增加。

另一个选择是创建一个名为dbo.GetDatabaseVersion的T-SQL函数，它会返回一个硬编码的值，你可以在需要时手动增加它的值。

Brett Gerhardi的建议是，为数据库版本创建一个扩展属性。参考以下例子：

EXEC sp_addextendedproperty @name='DbVersion',

@value ='1.015',

@level0type = NULL,

@level0name = NULL,

@level1type = NULL,

@level1name = NULL,

@level2type = NULL,

@level2name = NULL

如果不使用构造前脚本，那么你必须手动更新它的值。

持续集成

在理论上，你可以使用SqlPackage.exe自动部署数据库。Anuj Chaudhary在博客中发布了一篇帖子，名为“SqlPackage.exe —— 自动化SSDT部署”，为你介绍了这一过程。但在实践中，你会发现在某些场合中如果不对更新进行手动调整，对于SSDT来说处理会显得过于复杂。