在我的前一篇文章“Visual Studio 2008 Database Edition特性纵览”中，我介绍了VSDB的概况及它的主要特性。在本文，我将重点介绍如何使用它有效地管理数据库开发过程。

　　首先，让我们先了解一下开发一个项目会遇到的情况。当导入一个数据库到项目中时，我们会以“脱机方式”进行处理。每一个数据库对象和子对象都保存在一个文件中。例如，每一个表触发器或索引都对应自己的文件，而不是与表存在同一个文件。我们必须使用T-SQL编辑器去修改数据库对象，因为即使是现在这个版本也还没有用户接口（UI）编辑器。而对于经验较少的数据库开发人员来说这是很难的事，但这也是提高Data Definition Language （DDL）技术的一个很好的方法。

　　在项目中，我们可以修改已有的对象或添加新对象。这些修改不会应用到原始数据库，除非我们重新连接数据库并将修改部署到数据库或者运行部署过程中产生的脚本。而VSDB则使用存储于后台的一个文件中的验证模型。这是对上一个版本的修改，上一个版本中VSDB是通过产生一个验证数据库来检查脚本的。当在数据库库项目中保存一个修改后的脚本时，VSDB会将脚本与模型进行对比并应用有效的修改。但如果脚本验证失败，可能是语法错误、名称冲突或其它错误，VSDB会在项目中标记出这个文件并显示错误信息。如果我们尝试创建有一个或多个验证失败的对象的项目时，创建过程会失败，并且我们必须解决这些问题后才能创建这个数据库。

　　对于数据库对象，我们可以选择2种视图。Solution Explorer视图显示按对象类型（表、索引、视图等）分类目录中的对象。这个视图也是项目文件结构的物理表现：我们所看到的就是文件在磁盘中存储的方式。另一个视图是Database Schema视图，它是按照SQL Server Management Studio方式分层次的。其中有一组顶层对象，如表或存储过程，然后可以进入更低层次的对象，如索引、主键或约束。

　　我觉得Database Schema视图操作起来更容易，并且不太可能破坏项目组织。例如，当我们在Solution Explorer打开“New Item”对话框时，它会选中最后选择的一个对象类型。这意味着在创建一个存储过程后右击索引节点来创建一个新的对象时，VSDB会设置创建一个有“*.proc.sql”扩展名的文件。我们仍然可以将文件保存在CREATE INDEX代码内然后编译项目，但这个文件现在的扩展名是“.proc.sql”而不是“.index.sql”。然而，Database Schema视图则在添加一个新项目时提供了“Full Text Index”、“Index”和“XML Index”的选项。这可以避免用户不小心弄错对象类型和文件扩展名。

　　在修改、删除和添加新对象后，就可以编译数据库并生成部署文件了。点击“Build”按钮，VSDB会验证整个项目，处理所有的依赖并生成一个包含数据库模型的XML格式的模型文件，以及部署前、后脚本。然而，这个编译过程并不会和目标数据库作任何比较。当项目编译后，我们就可以进行部署了。运行“Deploy”命令，VSDB会对比编译生成的模型和目标数据库，然后生成一个部署脚本。生成的脚本包含了将在目标数据库中部署的所有修改的T-SQL文件。我们可以配置项目生成这个部署脚本，或者生成并部署到目标数据库上。

　　很多年来，我提出的一个观点是不要相信生成的脚本能够在生产数据库上运行。虽然从VSDB直接部署到非生产目标数据库可能是能够接受的，但你最好不要将他们部署到生产环境中。我建议要先检查脚本，以确保它没有任何会导致数据库产生问题的东西。生成的脚本实际上是一个SQLCMD脚本，然后在打开部署设置时VSDB会在部署后直接执行这个脚本。如果你决定通过SQL Server Management Studio手动地运行脚本，那么就要确认将执行模式切换到SQLCMD。

　　执行脚本的另一个方法是从命令提示符或批处理文件上运行sqlcmd.exe，但这个方法会有一个问题：生成的脚本会包含下面的检查SQL Server名称和数据库名称的代码，要确认它们与项目中的名称相匹配：

　　如果服务器名不是DEVBOXYUKON或者数据库不是AWTest，那么上面的脚本会运行失败，这表示我们不能拿这个脚本在许多不同名称的数据库上运行。我们必须手动地删除这2个部分以使它能够在任何有正确模型的数据库上运行。虽然，我们可以在项目中使用Configuration Manager进行某种方式的修正并创建多个项目配置。每一个配置都允许在项目中定义唯一的配置，包括SQL Server连接、数据库名和脚本输出位置。然后我们为每一个配置编译一次，每一次生成的脚本都包含同步项目到目标数据库的代码。但是不管什么原因，如果我们不能从VSDB连接到生产（或另一个）服务器，那么我们仍然需要删除这些服务器名检查代码或者修改服务器名。

　　在修改这些脚本后，我们应该保存它们或者将它们提交到SourceSafe中。如果不这样做，后面的部署过程会覆盖它们。从设计的观点上看，如果每一个项目配置都有生成或不生成检查服务器名称和数据库名称的代码的选项，那么将会更有意义。

　　结论

　　VSDB是一个功能很强大且很有用的管理数据库开发周期的工具，它也有一套使数据库开发过程变得简单的工具。虽然这个产品的某些方面仍然有待改进，甚至在它的第二版本也存一些不足，但是它的主要特性已经足以让我们在工具集中使用VSDB了。