我目前正在开发一个web项目，在这个项目中我们都连接到一个开发数据库。请提出一个更好的方式来组织开发数据库
和其他集中式系统一样，这个数据库最终成为单点故障。
如果其中一个开发人员不小心将一些脏数据转储到数据库中，则所有其他开发人员都会受此影响。
因此，我认为也许我们应该做一些事情，比如说，我们每个人都制作了原始数据库的副本，并设置了我们的Web应用程序以连接到本地数据库。
就我而言，团队的核心成员是五个开发人员，一个测试人员（主要是黑盒测试）。开发过程如下所示：每个开发人员负责一个子功能并在他自己的分支上工作，然后我们将他的分支合并到测试人员测试应用程序的主干上。
请给我一些建议。
让每个人都从他们自己的数据库副本中发展出来的问题是，他们不会接受其他开发人员的更改。
例如，如果有人向数据库表中添加一列，其他开发人员将不会意识到这一点。其他人也可能无意中添加同一列。
而且，如果有人以需要更改应用程序代码的方式更改存储过程（例如，添加输入参数），其他开发人员将不会知道这一点。如果他们从源代码控制中获得更新的代码，它将无法在本地数据库副本上工作。
我同意有一个日益混乱的开发数据库是一个问题。但我不确定从数据库的多个副本开发是否会减少开发问题的数量。
我认识到的一种替代方法可能不适用于您，它会定期将生产数据库复制到开发中。通常，这只能在新版本发布后进行，这会使生产数据库模式需要进行任何更改。但是你必须有一个生产数据库来做到这一点。
就我个人而言，我发现同步开发人员更改更容易 - 您需要讨论它们以免发生冲突 - 以及代码更改，而不是尝试使多个人员针对单个实例处理非同步代码。以更大的粒度级别强制代码/数据库同步似乎允许每个人的移动速度比如果他们必须始终不断更新其本地代码副本以匹配单个数据库。请注意，我正在讨论整合双周，每次迭代（最坏情况）而不是每天。我不会让这些变化漂移得太远。 – tvanfosson 2010-01-06 13:21:09
我同意你有一个本地数据库副本的缺点。也许这就是只能通过专注于问题本身而不是寻找最佳实践才能解决的问题。 – satoru 2010-01-06 13:29:04
Red Gate（我工作的人）将用一种名为SQL Source Control的产品解决这个问题（http://www.red-gate.com/Products/SQL_Source_Control/index.htm）。这将不会出现几个月，但同时您可以将开发人员数据库与SQL Compare进行同步。 – 2010-01-06 22:05:38
在我的项目上，开发数据库总是在开发者本地机器上。我们使用SQL Server Developer Edition或SQL Server Express。我们保留一个用于在源代码库中创建签入数据库的SQL脚本。任何需要重新创建本地数据库的人都可以使用它。一个团队成员负责维护SQL脚本，并且首先将任何数据库更改发送给他（如通常的SQL脚本）。他从SCM获取最新版本的脚本，更新他的本地副本，并生成一个更新后的创建脚本，用于替换SCM中的脚本。同时伴随代码更改被检入到SCM中，以便代码和数据库同步。其他人都同步到这个版本。
这使人们可以自由地并行工作并根据需要进行模式更改，包括可能会丢失的实验更改。我们还使用本地数据库作为虚拟数据的源代码来进行本地应用程序的测试 - 而不是单元测试，我们通常将数据库模拟为此，但是集成和UI测试。保持本地数据库的独立性允许每个开发者根据需要为其测试进行设置，而无需与其他人协调。
我还应该提到，我们使用Red Gate's SQL Compare只在协调员的本地数据库处于正式签入版本时传播更改。这是删除和重新创建数据库的替代方法，可以更好地保留现有数据。根据DB的变化，这可能是一个微不足道的或有点复杂的操作。我们一直使用它来更新质量保证/测试和生产数据库，除非这些更改如此微不足道，以至于可以通过手工完成（没有错误）。
我应该认定这是说这一直是一个相对较小的团队。我认为它会扩大或适应更大的团队（团队？），但我没有任何直接的经验。 – tvanfosson 2010-01-06 13:23:29
对我的公司来说工作得很好的解决方案是为每个开发人员在虚拟机中运行数据库。
我们为每个支持的数据库（oracle，db2，mssql，mysql）设置了一个虚拟机。现在每个开发人员都可以在本地简单地复制和运行虚拟机，而无需安装它。
我发现花时间建立一个系统，每个开发人员都有自己的数据库，每次运行他们的单元测试时都会刷新，重建并填充测试数据，这非常有帮助。通过这种方式，你永远无法彼此相处。当然，持续集成和测试服务器也应该有自己的数据库。
只要DDL和测试数据在版本控制中，每个人都在针对同一个数据库工作。另一个优点是，如果我正在开发一个需要更改数据库的功能，则每个人都可以获得代码和DDL +测试数据。
在Java领域，DbUnit在我们的例子中与Hibernate Maven插件一起对此非常有帮助。当然，一个简单的自制解决方案可能会很好。
我们使用与其他人在此描述的大致相同的基本过程，并进行了一些重大更改。每个开发人员通常都有自己的数据库实例，并使用更改脚本进行管理。这里是详细信息：
由于模式更改脚本的版本号必须以文件名编码，因此两个开发人员都创建相同的版本脚本时可能会产生冲突，因此在点上会显得有点草率。有时您可能会遇到处于不一致状态的数据库，并且自动过程将失败。但总的来说，它对我们来说工作得非常好。
贵公司有多大？你有开发，测试和生产环境吗？你有专门的测试团队吗？有很多变数，这是一个非常广泛的问题。 – 2010-01-06 13:06:11