我项目中的一些人似乎认为使用一个公共的开发数据库让每个人都连接到它是最好的事情。我认为并非如此,每个拥有自己的数据库(具有定期更新的数据转储)的开发人员都是最好的。我是对还是错?您在这些方法中遇到过任何问题吗?
6 回答
磁盘空间和 CPU 应该足够便宜,每个开发人员都可以运行自己的数据库实例,并在版本控制下自动构建。这是为了让开发人员能够大胆地对数据库进行黑客攻击,与任何其他开发人员的并发黑客行为隔离开来。
当然,需要注意的是,他们对私有实例所做的任何更改对其他人都是无用的,除非它可以在构建过程中自动应用。所以需要有一个坚定的政策,应用程序代码不能依赖于任何数据库状态,除非该状态由对DDL的版本控制、单元测试的更改表示。
有关将数据库定义视为项目代码的另一部分以及协调更改和重构的理论和实践的优秀指南,请参阅Scott W. Ambler 和 Pramod Sadalage 的Refactoring Databases: Evolutionary Database Design。
我喜欢拥有自己的数据库副本用于开发,因为它使您可以灵活地快速更改事物,而不必担心它会如何影响其他人。
但是,如果所有开发人员都在破解他们自己的数据库副本,那么最终将每个人的工作合并在一起变得越来越困难。
我认为您可以通过让开发人员在日常开发过程中处理本地副本来获得两全其美的效果,但是每个开发人员都应该定期将他们的工作合并到一个通用副本中。编写大量单元测试也有帮助。
我们在所有开发人员(20 多名)中共享一个数据库,但我们对其进行了结构化,以便每个人都有自己的表。
如果您正确构建应用程序,则不需要每个开发人员单独的数据库。它应该可以配置它使用的数据库或表前缀,以便您可以轻松地在实例之间移动它(单元测试、系统测试、验收测试、生产、灾难恢复等)。
使用单个数据库的优点是可以摊销维护成本。您不会让您的 DBA 尝试处理大量数据库(或者,如果您是一家小型数据库商店,则不会让每个开发人员在更好地用于开发时都尝试维护他们自己的数据库)。
单点故障不是一件好事,不是吗?
我更喜欢单一的共享数据库。但这在很大程度上取决于情况和正在开发的应用程序。
对我有用的东西可能对你不起作用。跟着你的直觉走。
如果您正在使用 Hibernate 或任何基于 hibernate 的平台,您可以将数据库配置为在启动服务器时创建(create-drop 选项)。当您向类添加新属性时,这非常有用。如果是这种情况,每个开发人员都必须拥有自己的数据库副本。
如果您根本不更改数据库结构,那么您可以使用单个共享数据库。在这第二种情况下不是必须的。我更喜欢拥有自己的数据库,在那里我可以做任何我想做的事情。另一方面请记住,某些查询可能会花费大量时间,如果您共享数据库,这将影响您的整个团队。