在项目开发工作中，数据库的更新维护一直是比较头疼的问题，特别是在一个项目要部署到多个目的地，并且不同目的地的数据库可能不一致的情况下，如果没有较好的维护工具，将需要大量的人工维护工作，如果在开发工作中合理使用数据库项目，将会简化大量的人工维护工作。
VS 数据库项目简介
在 MSDN 网站上，有关于数据库项目的详细介绍，不再这里啰嗦。个人的看法就是，让DBA（数据库管理员）也参与进来，把对直接对数据库的修改转换成相应的 SQL 语句，结合源代码管理，自动保留数据库更改历史，数据库项目的部署工具可以自动对比目标数据库与数据库项目当前的差异，然后生成一个针对目标数据库的更新文件，在目标数据库上执行这个文件，即可将目标数据库更新至当前版本。
VS 数据库项目开发生命周期
1、建立项目环境
首先，DBA 创建一个数据库项目并从成品数据库中导入数据库架构。然后，DBA 可以创建一个数据生成计划，以便创建要在独立开发环境中使用的测试数据。最后，DBA 将该数据库项目签入到版本控制中，以供团队使用。 
2、数据库项目迭代开发
每位数据库专业人员都与版本控制同步其开发环境。他们可以在文件更改后签出文件，并在独立环境中对这些更改进行开发和测试。这样，他们对自己的数据库项目副本所做的更改仅会部署到各自的独立开发环境中。当某位团队成员生成实际测试数据并对数据库的私有副本运行单元测试时，该团队成员便将这些更改签入到版本控制中。其他团队成员将从版本控制中获取经过测试的更改。 
3、生成项目的每日版本
每日版本是通过与数据库项目在版本控制系统中的最新测试版本进行同步而生成的。可以将该版本部署到测试数据库中，然后对生成的测试数据运行单元测试。 
4、从项目环境中进行部署
到了将数据库的某个版本部署到生产环境中时，DBA 将与版本控制系统中的标签同步。然后，DBA 检索数据库项目的匹配文件、相关脚本和测试。接下来，DBA 生成 .dbschema 文件。从 .dbschema 文件，DBA 将生成部署脚本并根据需要进行手动修改，然后对临时服务器执行测试部署。DBA 重复此过程，直到可以将该脚本部署到成品服务器为止。如果 DBA 更改了架构、预先部署脚本或后期部署脚本，则这些更改将被重新签入到版本控制中。 
数据库项目开发示例
1、数据表字段修改
假设项目中有一个数据表 MapDocument ， 现有两个字段， Id 以及 Name ，对应的表语句如下：
|
1
2
3
4
5
|
CREATE
TABLE
[dbo].[MapDocument]
(
[Id]
INT
NOT
NULL
IDENTITY(1,1),
[
Name
] NVARCHAR(50)
NULL
)
|
现在需要添加两个字段，Owner 和 CreateDate，将上面的 Sql 语句改成下面的样子：
|
1
2
3
4
5
6
7
|
CREATE
TABLE
[dbo].[MapDocument]
(
[Id]
INT
NOT
NULL
IDENTITY(1,1),
[
Name
] NVARCHAR(50)
NULL
,
[Owner] NVARCHAR(20)
NOT
NULL
DEFAULT
(‘Anonymous’),
[CreateDate] DATETIME
NOT
NULL
DEFAULT
(GETDATE())
)
|
2、部署到数据库服务器
- 如果 VS 能够直接连接到数据库服务器并且可以直接更新的话（不需要经过 DBA 检查），那么部署工作将十分简单，在项目属性页的部署标签页， 将部署动作设置为“创建部署脚本并部署到数据库”（如下图所示），则直接在 VS 中执行部署命令即可。
- 如果不能直接更新数据库的话，则需要将部署动作设置为“创建部署脚本”，生成部署脚本，然后由 DBA 或者实施人员负责更新。
注意事项
- 如果有多个数据库服务器需要更新的话，由于这些数据库的版本可能不同，因此必须针对每个数据库服执行部署命令，这样可以针对数据库服务器的结构生成相应的部署脚本；
- 如果部署选项是选择部署到文件的话，则执行部署命令只生成数据库更新文件，也就是一个 SQL 文件，在目标服务器上执行这个文件时要注意选择 SQLCMD 模式，否则将无法执行；
- 生成的数据库更新文件只是针对特定目标数据库的，最好不要拿到其它的数据库服务器上运行，必须针对数据库重新执行部署命令，生成一份新的部署文件进行更新；
张志敏所有文章遵循创作共用版权协议，要求署名、非商业 、保持一致。在满足创作共用版权协议的基础上可以转载，但请以超链接形式注明出处。
本博客已经迁移到 GitHub ， 围观地址： http://beginor.github.io/
