是否可以使用 MS VS 数据库项目作为数据库版本控制的完整解决方案？
在我们的项目中，我们有几个生产数据库和许多开发人员。每个生产数据库代表一些“子项目/本地化版本”。我们使用 SQL Server 2008。
因此，我需要使用 MS Visual Studio 数据库项目开发数据库版本控制策略。 我读了很多关于数据库版本控制和数据库项目的文章，但仍然有很多疑问：
开发人员应该如何实现 他们对数据库项目的更改？ （最佳实践）
如何生成 100% 可行的 “最新版本”部署脚本 无需人工干预（跳过 一些对象，重写一些更改， 等等）？
如何使用 MS 管理数据更改 Visual Studio 数据库项目？我 了解部署前/部署后脚本， 但我认为它无法解决这个问题 问题。 （示例：我需要重新映射 一些表到另一个表中）。
“理想的解决方案”是：
开发人员生成并维护数据库 [ProductionDB] 的数据库项目。
在新版本中，我将数据库项目部署到 [ProductionDB] 以及所有必要的内容 更改。
开发人员更改数据库项目并为具体更改编写一些数据操作脚本。
在新版本中，我将数据库项目部署到 [ProductionDB] 并进行所有必要的更改。
所以，最后一个问题：是否可以将数据库项目用于上述目的，或者有人使用类似的场景/解决方案？
PS：我已经阅读了以下讨论：
In our project we have several production databases and many devs. Each production database represents some "sub-project/localization version". We use SQL Server 2008.
So, I need to develop database versioning strategy using MS Visual Studio Database Project.
I have read a lot of articles about database versioning and database projects, but I still have a lot of questions:
How developers should implement
theirs changes to db project? (Best practice)How to generate the 100% workable
"latest version" deploy script
without human intervention (skipping
some objects, rewriting some changes,
etc)?How to manage data changes with MS
Visual Studio Database Project? I
know about pre-/post-deploy scripts,
but I think it cant resolve this
problem. (Example: I need to remap
some table into another).
The "ideal solution" would be:
Developers generates and maintains Database Project for database [ProductionDB].
With new release I deploy Database Project to the [ProductionDB] with all necessary
changes.Developers changes Database Project and writes some data manipulation scripts for concrete changes.
With new release I deploy Database Project to the [ProductionDB] with all necessary changes.
So, The final question: Is it posible to use Database Project for the purposes described above or somebody uses similar scenario/solution?
PS: I have already read following discussions:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
正是出于您在此处提到的大多数原因，才使用数据库项目 -
开发人员只需签出数据库脚本文件，进行更改，然后将它们重新签入。请注意，他们将更改 .sql 文件，而不是直接更改任何开发数据库中存在的对象。因此，如果您需要向数据库表添加两列，您将修改该表的创建表脚本，而不是为此表编写更改脚本。
如果您有目标旧版本数据库架构 - 您只需将此项目与最新文件部署到该数据库，然后将创建一个部署脚本（带有必要的更改语句）。有一个项目设置允许您选择在“部署”时是否也应该针对数据库运行部署脚本。
部署脚本可以是针对产品副本单独测试的可交付成果，然后作为补丁应用于产品。
关于数据操作脚本我不太确定，但是对于您提到的所有其他目的，数据库项目是完美的。
Database project is precisely used for most of the reasons that you have mentioned here -
Developers just checkout the database script files, make the changes, and check them back in. Mind you they will be changing .sql files and not directly the objects present in any dev database. So if you need to add two columns to a database table, you will modify the create table script for this table, and NOT write an alter script for this table.
If you have the target old version DB schema - you can just deploy this project with the latest files to that database and a deployment script will get created (with the necessary alter statements). There is a project setting that allows you to opt whether the deployment script should also be run against the db when you 'deploy'.
The deployment script can be a deliverable that is separately tested against a prod copy and then applied to prod as a patch.
About data manipulation scripts I am not very sure, however for all other purposes that you mentioned, a database project is perfect.
您所描述的是数据库项目存在的原因。
回答您的问题：
这取决于开发人员。您可以在 Visual Studio 中工作并直接编辑项目文件，或者在 Mgmt Studio 中编辑数据库的实时副本并使用 VS 中的架构比较将更改同步回项目。我已经使用它几个月了，发现两者都工作得很好，尽管我倾向于更频繁地直接编辑项目文件。
如果您选中首先删除目标数据库的框，则部署项目会生成最新版本。您可以通过在构建期间调用 VSDBCMD 来完成此操作，无需人工干预
部署前/部署后脚本正是针对您所提到的内容。一个示例是，将表中的所有数据选择到临时表中，并在预部署期间将其截断，让项目处理架构迁移，然后在部署后将其添加回来。这可能会很棘手，但这个问题从来都不容易解决。
希望这有帮助。
What you've described is the reason the database project exists.
To answer your questions:
It's up to the developer. You can either work in visual studio and edit the project files directly OR edit a live copy of the database in Mgmt Studio and use schema compare in VS to sync the changes back to the project. I've been using it for a few months and find both work fine, though I tend to edit the project files directly more often.
Deploying the project generates latest version if you check the box to drop the destination db first. You can do it with no human intervention by calling VSDBCMD during your build
The pre/post deployment scripts are meant for just what you allude to. An example would be to select all the data from a table into a temporary table and truncate it during the pre-deploy, let the project handle the schema migration and then add it back during post-deploy. That can get tricky, but that problem has never been easy to solve.
Hope this helps.
数据问题是一个很难解决的问题。在 Red Gate，我们收到了许多对 SQL 源代码控制工具的请求，这与 VS 数据库项目有相似之处。好消息是，我们正在积极增加对此的支持，并且应该在圣诞节前有一个早期版本进行尝试。如果您有兴趣，只需在 http://www.surveymk.com/s 注册抢先体验通知/SqlSourceControl_EapSignup 。我们很乐意收到您的反馈。
The data issue is a difficult one to solve. Here at Red Gate we've had many requests for this for our SQL Source Control tool, which has parallels with VS Database Projects. The good news is that we're actively adding support for this, and should have an early build to try out before Christmas. If you're interested, simply sign up for Early Access notifications at http://www.surveymk.com/s/SqlSourceControl_EapSignup . We'd love to get your feedback.
您可能想看看开源 bsn ModuleStore 工具包，它尝试来实现这个工作流程（它实际上还做更多的事情）。
You may want to have a look at the open-source bsn ModuleStore toolkit, which tries to implement this workflow (and it actually does also do more then that).