如何管理和捕获多个开发人员之间的数据库更改？
我们有三名开发人员和一名测试人员，他们都在同一个数据库上工作。我们经常更改数据库的模式，每次这样做都会产生连锁反应，让其他人感到头疼。
针对 MS SQL Server 2008 的面向 .NET 的开发是否有良好的实践来管理此问题？我正在考虑类似于 Rails Migrations 的东西，每个开发人员和测试人员都有自己的本地数据库。或者说这太过分了？拥有单独的测试和开发数据库至少是件好事，但目前手动保持两个数据库同步可能比我们当前的困境更糟糕。
LiquiBase 看起来很有前途，有人在类似的环境中成功使用过它吗？或者有更好的方法吗？
如果重要的话，我们正在使用 SQL Server 2008、VS 2008 和 .NET 3.5。
We have three developers and one tester all working against the same database. We change the schema of the database quite often, and every time we do it tends to have a ripple effect of headaches for everyone else.
Are there good practices in place for .NET oriented development against MS SQL Server 2008 for managing this? I am thinking something similar to Rails Migrations and each dev and tester has their own local database. Or is that overkill? It'd at least be nice to have separate test and dev databases, but currently manually keeping two databases in sync is probably worse than our current predicament.
LiquiBase seems promising, has anyone successfully used it in a similar environment? Or are there better approaches?
We are using SQL Server 2008, VS 2008 and .NET 3.5 if that matters at all.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我属于“单一开发数据库”阵营。
与传统的面向对象源代码不同，数据库通常具有支持多个用户功能的表。当多个开发人员要进行类似的更改时，您可以让他们提前解决或尝试同步两个构建脚本。构建脚本和迁移的问题在于大多数情况都非常重要。想要禁止数据库中存在 NULL？ - 您需要决定数据应默认为什么以及数据是否应从其他地方填充。需要重构将一个表规范化为两个表吗？ - 您需要决定如何分配按键。然后两个用户对同一个表进行更改...
这并不是说它不应该受到源代码控制，因为它应该受到源代码控制。
最终，当您拥有更多的开发人员和更多的沟通渠道时，您将希望通过开发 DBA 来更改数据库 - 这可以使更改得到协调并避免团队中沟通渠道的许多问题 - 它可以转变沟通方式通道变成恒星。
此外，如果您限制自己针对显式数据库服务层（如视图和存储过程）进行编程，那么您的应用程序开发人员将能够很好地免受数据库更改和重构的影响。
经过一定时间的开发后，数据库更改变得相当易于管理，因为对底层基表模式的更改较少（尽管视图和存储过程可能仍然不稳定）。
I'm in the "one development database" camp.
Unlike traditional OO source code, the database is often going to have tables supporting multiple users' features. When multiple developers are going to make similar changes, you can have them work it out in advance or try to sync two build scripts. The problem with build scripts and migrations is that most situations are non-trivial. Want to dis-allow NULLs in the DB? - you need to decide what the data should be defaulted to and if the data should be populated from elsewhere. Need to refactor to normalize a table into two? - you need to decide how to assign the keys. And then with two users making a change to the same table...
That's not saying that it shouldn't be under source control, because it should.
Ultimately as you have more developers and more communication channels, you are going to want your database changes going through a development DBA - this allows the changes to be coordinated and avoids a lot of the problems with communication channels in a team - it turns the communication channels into a star.
In addition, if you limit yourself programming against an explicit database services layer like views and stored procs, your application developers are going to be well insulated against database changes and refactoring.
After a certain time into development, database changes become pretty manageable, since the changes to the underlying base table schema are fewer (although views and stored procs may remain volatile).
听起来您需要一个数据库差异工具来创建和存储数据库更改...
Red Gate SQL 比较
Visual Studio 团队数据库版
Sounds like you need a database diff tool to create and store your database changes...
Red Gate SQL Compare
Visual Studio Team Database Edition
我个人认为最好有单独的数据库。所有针对一个数据库的工作都会造成很大的痛苦并浪费时间。
例如，假设我正在研究性能问题，并且正在运行一些基准测试来测试数据库上的一些优化 - 可靠地做到这一点的唯一方法是与测试保持一致。如果其他人中途对数据库进行了更改，则可能会扭曲您的发现。
另外，如果我正在做某件事并且数据库发生了变化，而我不知道这给我带来了错误/意外行为，那么我可能会花费一定的时间来完成工作，然后才发现这是由于其他人所做的更改所致。
相反，我认为最好拥有自己的开发/测试数据库，每个人都可以负责更新。然后拥有一个持续集成服务器，它会自动从源代码控制中提取最新代码并每 x 小时构建一次。
I personally think it's best to have separate databases. All working against one database can cause a lot of pain and waste time.
For example, say I'm looking into a performance issue and I'm running some benchmark tests to test out some optimisations on the database - the only way you can do this reliably is if you are consistent with your tests. If someone else makes a change to the DB midway through, that could skew your findings.
Plus, if I'm in the middle of something and the DB changes without me knowing causing errors/unexpected behaviour for me, I could spend x amount of time just working through before finding out it's due to a change someone else has made.
Instead, I think it's much better to have your own dev/test databases which you can each be responsible for updating. Then have a Continuous Integration server that automatically pulls out the latest code from source control and builds it every x hours.
我们本身不使用工具，但我们确实将所有架构置于源代码控制之下，然后有一个脚本可以从源代码更新或重建数据库。这样，当发生更改时，我们都可以更新并保持同步。这只是每天早上例行公事的一部分，大约需要 5 分钟，就像同步代码一样。这并不完美，但对我们有用。
哦，我忘了添加，如果您对架构进行更改，您还负责编写迁移脚本（如果需要）。无论如何，当产品投入生产时，这往往是需要的。
希望有帮助。
We don't use a tool per se, but we do keep all of our schema under source control and then have a script that will update or rebuild the databse from source. This way when changes are made we can all update and stay in synch. This just becomes part of the daily morning routine, takes about 5 minutes just like synching up your code. This isn't perfect but it works for us.
Oh and I forgot to add if you make changes to schema you are also responsible for writing the migration script if any is needed. This tends to be needed anyway when something gets to production.
Hope that helps.
Visual Studio Team System 数据库版（又名“Data Dude”）是值得研究。它可以跟踪数据库差异并生成更改脚本，以便您可以在部署之前准备测试/生产环境等。我认为它的功能在开发版本中也可用（请参阅前面的链接），并且在 VS 2010 中将更加明显。看一下这篇博文：第一次体验Visual Studio 2008 数据库版，我喜欢它！！！
它与 TFS 一起使您能够对 SQL 文件进行版本控制并针对数据库运行它们。
Visual Studio Team System Database Edition (aka "Data Dude") is worth looking into. It can track database diffs and generate scripts of the changes so you can prepare a test/prod environment prior to deployment etc. I think its features are also available in the Development edition (see previous link) and in VS 2010 will be more visible. Take a look at this blog post: First Experience with Visual Studio 2008 Database Edition, I love it!!!
That, along with TFS, gives you the ability to version control the SQL files and run them against the database.
一些好链接的好链接： http://www.codinghorror.com/blog/2008/02/get-your-database-under-version-control.html
A good link to some good links: http://www.codinghorror.com/blog/2008/02/get-your-database-under-version-control.html
我们有从头开始生成数据库的脚本，这就是源代码管理中的内容。
每个开发人员（其中 20 名）使用脚本在其工作站上生成 2 个数据库。一种用于“工作”——使用其中的示例数据进行手动测试（有脚本来填充示例数据）。另一个数据库是空的，用于单元测试（打开事务 - 进行单元测试 - 回滚）。
在多开发环境中单元测试是强制性的。
此外，我们总是构建“旧”数据库并对其应用架构更改。每个开发人员都通过创建升级过程来更改架构（这就是我们同时准备好重建和升级的方式）。
对于性能测试，我们有“加载程序”——C# 代码来模拟用户并在夜间在开发人员工作站上填充数百万条记录。
We have scripts to generate DB from scratch and this is what is sitting in the source control.
Each developer (20 of them) is using script to generate 2 databases on their workstations. One for “work” – manual testing with sample data in it (there is script to populate sample data). Another DB is empty and used in unit tests (open transaction – do unit test – roll back).
Unit test are mandatory in multi developer environment.
Also we always build “old” database and apply schema changes on it. Each developer is changing schema by creating upgrade procedures (this is how we have rebuild and upgrade ready at the same time).
For performance testing we have “loaders” – C# code to simulate users and populate millions of records over night on developer workstations.