我们应该为每个开发人员拥有单独的数据库实例吗？
开发基于数据库的应用程序的最佳方法是什么？我们可以有两种方法。
- 所有开发人员的通用数据库。
- 为所有开发人员提供单独的数据库。
各自的优点和缺点是什么？哪一种方法更好？
编辑： 应该有不止一个开发人员来更新数据库，并且我们已经在每台开发人员计算机上安装了 SqlExpress 2005。
编辑：我们大多数人都建议使用一个通用数据库。但是，如果其中一位开发人员修改了代码和数据库架构。他尚未提交代码更改，但架构更改已进入公共数据库。它不会破坏其他开发人员的代码吗？
What is the best way for developing a database based application? We can have two approaches.
- One common database for all the developers.
- Separate database for all the developers.
What are the pros and cons of each? And which one is better way?
Edit: More then one developer is supposed to update the database and we already have SqlExpress 2005 on each developer machine.
Edit: Most of us are suggesting a common database. However if one of the dev has modified the code and database schema . He has not committed the code changes but the schema changes has gone to the common database. Will it not possibly break the other developers code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
两者 -
我喜欢在上线或进入“正式”测试环境之前对更改进行测试的单个数据库。这是您的开发人员的健全性检查；它与实时系统保持同步，并确保他们始终考虑彼此的更改。规则应该是，如果更改可能会破坏其他内容，则不应在此处进行更改。
当多个开发人员进行更新时，每个开发人员拥有一个数据库是非常有用的（甚至是必要的）。它为他们提供了他们想要的所有开发灵活性，而不会破坏其他开发人员的东西。
关键是要有一个将数据库更改从开发转移到实际系统的流程，并坚持您的流程。
Both -
I like a single database that changes are tested on before going live, or going to a 'formal' test environment. This is your developer's sanity check; it stays up to date with the live system and it makes sure they always consider each others changes. The rule should be that changes don't go on here if they might break something else.
A database per developer is great (even essential) when more than one developer is making updates. It allows them all the development flexibility they want without breaking things for other developers.
The key is to have a process for moving database changes from development through to your live system, and stick to your process.
共享数据库
独立数据库
我们使用共享开发数据库，效果很好。我们的架构很少会发生向后不兼容的变化，但有时在我们上线之前会发生设计更改，我们只需要求其他开发人员进行更新即可。
我们确实有单独的开发应用程序（Web）服务器，但它们共享相同的数据库。我们的开发人员确实可以选择使用自己的数据库，因为他们知道如何设置它，并且有时会这样做，但只是暂时的。对我们来说，规范是共享数据库。
Shared database
Individual databases
We use a shared development database and it works out nicely. Our schema rarely changes in a way that makes it backwards incompatible, but occasionally a design change will occur before we go live, and we simply ask the other developers to update.
We do have separate development application (web) servers, but they share the same database. Our developers do have the option to use their own database, as they know how to set this up, and will do that on occasion, but only temporarily. The norm, for us, is to share the database.
我想我应该把这个扔掉，但为什么不让每个开发人员在他们的桌面上托管自己的 SQL Server Developer 实例，然后为每个其他环境（开发、QA 和产品）提供一个共享服务器呢？我认为即使是 Visual Studio Pro 附带的基本 MSDN（如果您选择它）也包含 SQL Server Developer 的许可证。
开发人员可以在自己的桌面上工作，而不会影响其他人，然后您可以让他们将代码移动到您认为合适的下一个共享环境（随意，每日/每周构建等）。
编辑：
我应该补充一点，桌面实例允许开发人员执行 DBA 在共享环境中经常限制的操作。这包括数据库创建、备份/恢复、分析器等。这些并不是必需的，但它们可以让开发人员变得更加高效，同时减少对 DBA 的要求。
共享环境对于测试来说是完全必要的——我不建议从桌面转向生产。但是，您可以通过允许开发人员以相对较小的成本对给定数据库环境进行 100% 的控制（包括与其他数据库环境的隔离）来添加更多内容。
Thought I'd throw this out there, but why not let every developer host their own instance of SQL Server Developer on their desktops and then have a shared server for each of the other environments (development, QA, and prod)? I think even the basic MSDN that comes with Visual Studio Pro (if you opt for it) includes a license for SQL Server Developer.
The developer can work on their desktop without impacting the others and then you can have them move the code to the next shared environment as you see fit (at will, with daily/weekly builds, etc.).
EDIT:
I should add that the desktop instance allows developers to do things that he DBAs often restrict on shared environments. This includes database creation, backup/restore, profiler, etc.. These things are not essential but they allow the developer to become so much more productive while reducing the demands they make against your DBAs.
The shared environment is completely necessary for testing - I would not recommend going from desktop to production. But you can add so much by allowing the developers to have 100% control over a given database environment (including isolation from others) with a relatively minor cost.
取决于您的开发、测试和维护周期。还有开发团队（当然还有组织）的规模和位置。如果您支持多个版本的数据库，您可能需要更多环境。
在现实世界中，我发现以下方法相当令人满意：
这里有一些进一步的要点：
如果两个开发人员（两个团队）正在进行可能相互影响的更改，那么他们应该独立完成任务，并且然后集成/合并并测试。为此，最好有单独的开发环境（除非他们必须一起工作，在这种情况下，我认为他们是同一团队的一部分；他们仍然可以处理自己的数据库副本，并在必要时共享它）
如果他们所做的更改不会互相影响，那么他们就可以在主服务器上工作。或者在他们自己的数据库本地副本上。
因此，在一般情况下（当您支持系统的多个版本并无论如何维护升级脚本时），在本地副本上进行开发具有所有好处，并且没有风险。
如果您可以共享测试用例，那就太好了，因此能够轻松快速地转储/恢复数据库是一个很大的优势。
编辑：
上述所有内容都假设在整个系统的本地计算机上有一个副本用于测试目的是可行的（大小、性能、许可证等）。
Depends on your development, testing and maintenance cycles. Also on the size and location of the development team (and of course organization). If you support several versions of the database you might need even more environments.
In real world I found the following approach rather satisfying:
Here are some further points:
If two developers (two teams) are working on changes that can affect each other then they should complete their tasks independently and then integrate/merge and test. For this it is much better to have separate development environments (unless they have to work together in which case I consider them to be a part of the same team; still they can work on their own copies of the database and share it if necessary)
If they work on the changes that do not influence each other they could work on the main server. Or on their own local copies of the database.
So, developing on the local copy has all the benefits with no risk in a general case (when you support multiple versions of the system and maintain upgrade scripts anyway).
Still it is great if you can share test cases so ability to dump/restore the database easily and quickly is a big plus.
EDIT:
All of the above assume that having a copy on the local machine of the whole system for testing purposes is feasible (size, performance, licenses, etc).
我会选择解决方案#1：为所有开发人员提供一个通用数据库。
优点
缺点
至于解决方案#2：为每个开发人员提供一个独立的数据库；
优点
缺点
考虑到上述情况，我会根据您的公司规模建议：
如果您的公司不需要集成测试，那么就进行验收测试，这一步在投入生产之前至关重要。
I would opt for solution #1 : One common database for all the developers.
Pros
Cons
As for solution #2 : One independant database for each of the developers;
Pros
Cons
Considering the above, I would recommend, depending on your company size:
If your company doesn't require integration tests, then go with acceptance tests, this step is crucial before going to production.
每个开发人员一个，加上一个持续集成和构建服务器来运行单元和集成测试。这让您两全其美。
一旦数据库更改量达到一定水平，让所有开发人员修改单个开发数据库很快就会降低生产力，因为它迫使开发人员在准备签入之前将更改部署到共享数据库，这意味着代码的其他部分线路可能会不必要地断裂。
One per developer plus a continuous integration and build server to run unit and integration tests. That gives you the best of both worlds.
Having all developers modify a single dev database quickly becomes less productive once the amount of database change reaches a certain level because it forces a developer to deploy changes to the shared database before he is ready to check-in, which means other parts of the code line may break unnecessarily.
简单的答案：
拥有一个开发数据库，如果开发人员想要自己的数据库，他们可以在自己的机器上运行自己的实例。请务必在共享上进行测试/发布。
Simple answer:
Have one development database, and if the developers want their own, they can just run their own instance on their own machines. Just be sure to test/publish on the shared.
我们两者都做：
我们在我所在的地方使用代码生成，并且我们的数据库也被生成。因此，我们在每个开发人员的盒子上都有一个生成数据库的实例。然后，我们使用生成的脚本将更改应用到中央测试数据库。如果进展顺利，我们将在发布期间将更改应用到生产数据库。
这种方法的好处是，当我们的“事实来源”签入源代码管理时，所有数据库更改都会在其他开发人员变基和重新生成时自动分发给他们。这对我们来说效果很好。
We do both:
We use code generation where I'm at and our database is generated as well. So we have an instance on each developer's box where the database is generated. Then we use the scripts that are generated to apply the changes to a central test database. If that goes well we apply the changes to the production database during a release.
What's nice with this approach is that when our "source of truth" is checked in to source control, all the database changes are automatically distributed to the other developers when they rebase and regenerate. It works well for us.
最好的方法是测试/QA 服务器上有一个数据库，每个开发人员有一个数据库（可能在开发人员的本地计算机上）（因此，10 个开发人员使用 10 + 1 个数据库）。
与一般开发相同的方法：每个开发人员在本地计算机上都有自己的源代码副本。
此外，多数据库方法简化了版本控制系统中数据库模式的保存。我们将数据库创建脚本保存在 SVN 中。
我们正在使用此处描述的方法：
http://www.sqlaccessories.com/Howto/Version_Control.aspx
The best way is single database on Test/QA server and one database (probably on developer's local computer) for each developer (so, 10 developers work with 10 + 1 databases).
The same approach as for general development: each developer has own copy of source code on local machine.
Also, multiple-database approach simplifies the keeping database schema in version control systems. We are keeping database creation scripts in SVN.
We are using the approach, described here:
http://www.sqlaccessories.com/Howto/Version_Control.aspx
您可能还想查看重构数据库。除了讨论数据库更改之外，他还讨论了如何以降低风险的方式从开发到生产。
You might also want to look at Refactoring Databases. Aside from discussing database changes, he includes discussions on going from development to production in a way that reduces risk.
到底为什么要为所有开发人员提供一个单独的数据库？
共用一个数据库，表结构一致，sql语句也一致。
Why on earth would you want a separate database for all developers?
Have one common database for all, that way the table structure is consistent and the sql statements are as well.
开发人员拥有自己的数据库的最大问题是：
实际生产数据库的数据（如果
你获取我们需要的所有数据库
与这里合作，他们会占用
几百GB的空间，我
我的上没有可用的
机），这会导致错误的代码
写的永远不会工作
大型数据库以提高性能
原因。永远不应该针对比产品上的数据集小得多的数据集编写 SQL 代码。
数据库创建问题时
花费很长时间开发
某事，然后才发现
当它们与真实的数据库合并后
它会影响其他东西。你
当您找到这些东西时，速度会快得多
共享环境。所以有
最终减少浪费的开发
时间。
需要了解有关变化的事情
你正在做的，这会影响他们
改变。
当你知道你会影响别人时，我认为你会更加小心你所做的事情，这在我的书中是一个优点。
现在共享数据库服务器应该有我们所说的临时数据库，人们可以在其中创建和测试表更改，因此如果他们正在做一些可能需要删除并重新创建表的事情（这应该是一种罕见的情况！），他们可以首先通过将表复制到临时数据库并在那里运行其流程来测试该流程，然后在确定其有效时更改为真实数据库。或者，我们经常在测试特定更改之前将备份表复制到临时数据库，以便在旧数据出现问题时可以轻松地重新创建旧数据。
我认为使用单独的数据库没有任何优势。
The biggest problems with developers having their own databases are:
of the real production database (if
you take all the databases we need to
work with here, they would take up
several hundred gigabytes of space, I
don't have that available on my
machine), this causes bad code to be
written that will never work on a
large database for performance
reasons. SQL code should never be written against a data set significantly smaller than the one on prod.
database create problems when they
spend a long time developing
something and then find out only
after they merge with a real datbase
that it affects something else. You
find this stuff much faster when you
share the environment. So there is
inthe end less wasted development
time.
things need to know about the changes
you are making, it will affect their
change.
When you know you are going to affect others, I think you tend to be more careful what you do which isa plus in my book.
Now the shared database server should have what we call a scratch database, a place where people can create and test table changes, so if they are doing something that might need to drop and recreate a table (which should be a rare case!), they can test the process first by copying the table to the scratch database and running their process there and then changin to the real database when they are sure it works. Or we often copy a backup table to the scratch database before testing a particular change, so we can easily recreate the old data if it goes bad.
I see no advantages at all to using individual databases.