Database 使用公共数据库进行协作开发

我项目中的一些人似乎认为使用一个公共开发数据库，每个人都连接到它是最好的。我认为并非如此，每个开发人员拥有自己的数据库（定期更新数据转储）是最好的。我是对还是错？您在这些方法中遇到过任何问题吗？

我们在所有开发人员之间共享一个数据库（20多个），但我们已将其结构化，以便每个人都有自己的表

如果正确地构造应用程序，则不需要每个开发人员都有一个单独的数据库。它应该可以配置使用哪个数据库或表前缀，以便您可以轻松地在实例之间移动它（单元测试、系统测试、验收测试、生产、灾难恢复等）

---

使用单个数据库的优点是维护成本可以摊销。你没有让你的DBA尝试处理很多数据库（或者，如果你是一家小型数据库商店，你也没有让每个开发人员在开发中更好地利用自己的数据库时都尝试维护自己的数据库）。

单点故障不是一件好事，不是吗？

我喜欢拥有自己的数据库副本进行开发，因为它能让你灵活地快速改变事情，而不用担心它会对他人产生什么影响

然而，如果所有开发人员都在自己的数据库副本上进行黑客攻击，那么最终将每个人的工作合并在一起就变得越来越困难

---

我认为，通过让开发人员在日常开发过程中使用本地副本，您可以获得两个方面的最佳效果，但每个开发人员可能都应该定期将他们的工作合并到一个通用副本中。编写大量的单元测试也有帮助。

我更喜欢单一的共享数据库。但这取决于实际情况和正在开发的应用程序

---

对我有效的可能对你无效。随机应变。

如果您使用的是Hibernate或任何基于Hibernate的平台，您可以将数据库配置为在启动服务器时创建（创建删除选项）。这在向类添加新属性时非常有用。如果是这种情况，每个开发人员都必须拥有自己的数据库副本

如果您根本没有更改数据库结构，那么可以使用单个共享数据库。

---

在这种情况下，第二种情况不是必须的。我更喜欢有自己的数据库，在那里我可以做任何我想做的事情。另一方面，请记住，某些查询可能需要大量时间，如果您共享数据库，这将影响整个团队。

磁盘空间和CPU应该足够便宜，每个开发人员都可以运行自己的数据库实例，并在版本控制下自动生成。这需要允许开发人员大胆地对数据库进行黑客攻击，与任何其他开发人员的并发黑客攻击隔离开来

当然，需要注意的是，他们对私有实例所做的任何更改对其他任何人都是无用的，除非它可以在构建过程中自动应用。因此，需要有一个明确的政策，即应用程序代码不能依赖于任何数据库状态，除非该状态由对的版本控制、单元测试更改表示

---

有关将数据库定义视为项目代码的另一部分以及协调更改和重构的理论和实践的优秀指南，请参见Scott W.Ambler和Pramod Sadalage。

Sql Server支持可用于相同目的的模式。