3

在我们的项目中,我们有几个生产数据库和许多开发人员。每个生产数据库代表一些“子项目/本地化版本”。我们使用 SQL Server 2008。

因此,我需要使用 MS Visual Studio 数据库项目开发数据库版本控制策略。我已经阅读了很多关于数据库版本控制和数据库项目的文章,但我仍然有很多问题:

  1. 开发人员应该如何实现他们对 db 项目的更改?(最佳实践)

  2. 如何在没有人工干预(跳过一些对象、重写一些更改等)的情况下生成 100% 可行的“最新版本”部署脚本?

  3. 如何使用 MS Visual Studio 数据库项目管理数据更改?我知道部署前/部署后脚本,但我认为它不能解决这个问题。(例如:我需要将某个表重新映射到另一个表中)。

“理想的解决方案”是:

  1. 开发人员为数据库 [ProductionDB] 生成和维护数据库项目。

  2. 在新版本中,我将数据库项目部署到 [ProductionDB] 并进行了所有必要的更改。

  3. 开发人员更改数据库项目并为具体更改编写一些数据操作脚本。

  4. 在新版本中,我将数据库项目部署到 [ProductionDB] 并进行了所有必要的更改。

所以,最后一个问题:是否可以将数据库项目用于上述目的,或者有人使用类似的场景/解决方案?

PS:我已经阅读了以下讨论:

  1. 数据库更改版本控制[关闭]
  2. 如何在 SVN 中对我的 MS SQL 数据库进行版本控制?
  3. 寻找数据库版本控制的解决方案
  4. 是否有用于数据库结构更改的版本控制系统?
4

4 回答 4

2

正是出于您在此处提到的大多数原因而使用了数据库项目-

  1. 开发人员只需签出数据库脚本文件,进行更改,然后重新签入。请注意,他们将更改 .sql 文件,而不是直接更改任何开发数据库中存在的对象。因此,如果您需要向数据库表添加两列,您将修改该表的创建表脚本,而不是为该表编写更改脚本。

  2. 如果您有目标旧版本 DB 架构 - 您只需将该项目与最新文件一起部署到该数据库,就会创建一个部署脚本(使用必要的 alter 语句)。有一个项目设置允许您选择在“部署”时是否还应针对数据库运行部署脚本。

  3. 部署脚本可以是一个交付物,针对产品副本单独测试,然后作为补丁应用到产品。

关于数据操作脚本我不太确定,但是对于您提到的所有其他目的,数据库项目是完美的。

于 2010-11-09T20:28:35.300 回答
2

您所描述的是数据库项目存在的原因。

要回答您的问题:

  1. 这取决于开发人员。您可以在 Visual Studio 中工作并直接编辑项目文件,也可以在 Mgmt Studio 中编辑数据库的实时副本并在 VS 中使用模式比较将更改同步回项目。我已经使用它几个月了,发现两者都可以正常工作,尽管我倾向于更频繁地直接编辑项目文件。

  2. 如果您选中复选框以首先删除目标数据库,则部署项目会生成最新版本。您可以在构建过程中调用 VSDBCMD,无需人工干预

  3. 部署前/后部署脚本仅适用于您提到的内容。一个例子是从一个表中选择所有数据到一个临时表中,并在预部署期间截断它,让项目处理模式迁移,然后在部署后将其添加回来。这可能会变得很棘手,但这个问题从来都不容易解决。

希望这可以帮助。

于 2010-11-09T21:30:13.947 回答
0

数据问题是一个难以解决的问题。在 Red Gate,我们对SQL 源代码控制工具提出了很多要求,该工具与 VS 数据库项目有相似之处。好消息是我们正在积极增加对此的支持,并且应该在圣诞节前进行早期构建。如果您有兴趣,只需在http://www.surveymk.com/s/SqlSourceControl_EapSignup注册抢先体验通知。我们很想得到您的反馈。

于 2010-11-14T19:23:16.137 回答
0

你可能想看看开源bsn ModuleStore 工具包,它试图实现这个工作流(实际上它还做了更多的事情)。

于 2010-12-09T00:41:02.943 回答