一个团队在同一个数据库上工作的最佳实践是什么？ 开发人员应该使用他们自己的本地数据库，还是一个共享的开发数据库实例？
当团队处理数据库时，最佳实践是什么？
10
- k0stya
3
这取决于数据库模式的设计（如果有设计的话），测试数据的复杂程度，数据库模式和内容的稳定性。随着开发的进行，可能会有所变化。 - pascal
什么是BD？那是DB的打字错误，还是我没有听说过的某个产品？ - Marcelo Cantos
我找到了这篇文章：http://odetocode.com/blogs/scott/archive/2008/01/30/three-rules-for-database-work.aspx
但我同意“pascal”的观点，这取决于数据库大小、架构和其他特征。 - k0stya
7个回答
13
根据我的经验，一个团队应该至少有一个共享数据库用于集成。
在开发过程中，每个团队成员都应该有一个独立的数据库，否则数据库模式的更改可能会妨碍其他团队成员。这些实例也可以存在于一个集中的服务器上。
- stacker
4
我只能谈论我所在团队的工作方式，这种方式足以满足我们的需求：
我们有一个中央数据模型脚本，可以自动更新任何数据库到最新的模式版本。开发人员与源代码一起提交更改（同一存储库的单个提交）到此脚本。每晚进行构建，更新中央数据库副本，然后在该数据库上运行一批自动化测试，第二天人类QA团队也使用同一数据库进行所有测试。
我们不允许通过集成构建之外的任何方式更改中央数据库实例的架构。为了开发架构更改脚本，更改将在单独的数据库实例上开发，可以是在中央服务器上或本地（取决于个人喜好）。
我们有一个中央数据模型脚本，可以自动更新任何数据库到最新的模式版本。开发人员与源代码一起提交更改（同一存储库的单个提交）到此脚本。每晚进行构建，更新中央数据库副本，然后在该数据库上运行一批自动化测试，第二天人类QA团队也使用同一数据库进行所有测试。
我们不允许通过集成构建之外的任何方式更改中央数据库实例的架构。为了开发架构更改脚本，更改将在单独的数据库实例上开发，可以是在中央服务器上或本地（取决于个人喜好）。
- Joeri Sebrechts
4
我认为这并不取决于任何因素。每个环境都应该有自己的数据库实例。就个人而言，我永远不会建议团队中的每个人都在同一份源代码副本上工作，我将数据库代码和实例视为同等重要。
如果您遇到缺少数据库更改的问题，则这是不同开发流程问题的症状。这类似于忘记将代码文件添加到源代码控制中。 Jeff Atwood在源代码控制数据库代码方面有一篇非常好的文章。 不同的开发人员据说处理不同的问题-如何在单元测试时避免互相干扰？
我绝对支持一个集成/测试环境，通过持续集成过程进行更新。这个环境通常也作为您的部署程序的试金石。
如果您遇到缺少数据库更改的问题，则这是不同开发流程问题的症状。这类似于忘记将代码文件添加到源代码控制中。 Jeff Atwood在源代码控制数据库代码方面有一篇非常好的文章。 不同的开发人员据说处理不同的问题-如何在单元测试时避免互相干扰？
我绝对支持一个集成/测试环境，通过持续集成过程进行更新。这个环境通常也作为您的部署程序的试金石。
- Zachary Yates
3
在Redgate，我们建议每个开发人员都有自己的实例，因为沙箱化可以确保开发人员不会互相干扰。然而，这两种模式都有优缺点。
根据我们与数据库开发人员的交流经验，大约一半的数据库开发是在共享环境中进行的，另一半则在专门为每个开发人员定制的环境中进行。
根据我们与数据库开发人员的交流经验，大约一半的数据库开发是在共享环境中进行的，另一半则在专门为每个开发人员定制的环境中进行。
- David Atkinson
1
我知道这里的人们都在谈论他们的过去经验，但是这并不是一个普遍易答的问题。每种方法都有其优缺点，应根据应用程序类型和团队状况进行评估。
如果你不知道该选择哪种方法...我建议先使用共享开发数据库来查看是否遇到任何问题。如果此解决方案有效，则应该是首选方法，因为它可以消除“集成”步骤。然而，根据团队和环境需求的不同，您可能需要进行调整。
如果你不知道该选择哪种方法...我建议先使用共享开发数据库来查看是否遇到任何问题。如果此解决方案有效，则应该是首选方法，因为它可以消除“集成”步骤。然而，根据团队和环境需求的不同，您可能需要进行调整。
- sam yi
1
从经验来看，共享数据库更好。我们的代码过去经常出问题，因为有人在他们的本地数据库上添加了一列，然后将他们的新源代码上传到 SVN。直到其他人弄清楚数据库中发生了什么变化之前，每个人的实现都会受到影响。
我会为开发使用一个共享数据库。我们也有一两个用于杂项测试的开发数据库。
- NibblyPig
2
如果有人在数据库中更改了列类型，但没有上传ORM模式，会发生什么情况？ - k0stya
1我们以同样的方式处理应用程序代码和数据库代码（存储过程，模式更改）。我们偶尔会忘记更新数据库，但开发人员很快学会了，他们宁愿不让我们识别出有问题的代码，这在持续集成和测试下并不太难。我们有一个规则，在提交之前需要编写升级脚本，并编写针对数据库运行的自动化测试。 - aqwert
1
为开发人员拥有单独的数据库实例可以帮助他们在隔离环境中工作，但如果我们是一个大团队并且同时处理多个任务，则最好也拥有共享环境，以便所有需要同时交付的更改不会相互冲突，并且它们的依赖关系也可以正确地确定。这也有助于确定由于更改而可能导致任何应用程序崩溃的位置。因此，最好除了一些隔离的环境副本外，还要有一个共享环境，以防我们可能想要测试某些非常重要且必须正常工作的大型复杂内容。
但唯一的问题是保持多个环境彼此同步，因为任何缺失的更改都可能是致命的。
- Neo
1
是的，拥有单独的数据库和共享环境进行“集成”测试显然是理想的选择，如果您考虑一下，这就是持续集成所提供的。开发人员应该在各自的沙盒中进行开发，将更改提交到源代码控制中心，触发持续集成，构建并测试包含所有更改的数据库。 - David Atkinson
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接