一个新的 BI/数据库项目：如何对数据库进行版本控制？
我们正在公司启动一个新的 BI 项目。我们至少有三名开发人员从事数据库设计和开发。我们的工具包括 Sparks EA、SQL Server 2008 EE 和未确定的报告工具。 SQL Server 中可以使用哪些工具进行数据库版本控制？有哪些类型的版本控制系统可用于数据库开发（管理数据库模式、表、存储过程等的版本）？
We are starting a new BI project in our company. We have at least three developers working with database design and development. Our tools include Sparks EA, SQL Server 2008 EE and undetermined reporting tools. What kind of tools one can use for database version control in SQL Server? What kind of version control systems there are available for database development (managing versions of database schema, tables, stored procedures etc.)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Visual Studio Team System 包括用于数据库源控制、部署、架构比较等的数据库版本功能。您不一定需要一个工具来进行数据库版本控制，但如果您确实需要一个工具，那么 VSTS 是一个选择。
Visual Studio Team System includes the Database Edition features for database source control, deployment, schema comparison and more. You don't necessarily need a tool to do database versioning but if you do want a tool then VSTS is one option.
通常，导出一组从头开始创建数据库的脚本并将其置于版本控制中会更容易。
然后，如果您想从源代码控制将数据库升级到“版本”，您可以使用 SQL Compare 或“Data Dude”等工具来比较两个数据库（或创建脚本和数据库），并将更改从一个数据库应用到另一个数据库。另一个。
Often it's easier to export a set of scripts that would create your database from scratch, and put those in version control instead.
Then, if you want to upgrade a database to a "version" from source control, you could use a tool like SQL Compare or "Data Dude" to compare two databases (or creation scripts and a database) and apply the changes from one to the other.
我们在脚本中创建所有数据库更改，从不使用 GUI。然后将脚本保存在 Subversion 存储的文件夹中，就像任何其他代码一样。由于我们的配置管理人员不会在没有脚本的情况下推送到生产环境，因此我们在执行此操作时完全没有问题。美妙之处在于，您将特定更改所需的所有脚本放在一起，并且另一个更改中尚未准备好进行生产的脚本不会被意外推送。
我们也将所有 SSIS 包存储为文件，并将配置存储在脚本中，并以相同的方式推送它们。
如果您想在数据库之间进行比较以确保没有遗漏任何内容，我强烈推荐 Red-gate 的 SQLCompare。
We create all database changes in scripts, never use the GUI. Then save the scripts in folders that are part of our Subversion store just like any other piece of code. Since our configuration management people will not push to prod without a script, we have no rtrouble at all enforcing this. The beauty is that you have all the scripts you need for a particular change located together and those in another change not yet ready to go to prod are not pushed by accident.
We store all our SSIS packages as files as well and we store our configurations in sripts as well and push them the same way.
Should you want to do a comparison between databases to make sure nothing was missed, I highly recommend SQLCompare by Red-gate.