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 回答