我正在使用PHP＆amp; MySQL的。我终于掌握了源代码控制，并对PHP部分的整个开发（测试）v生产v存储库事件感到非常满意。
我的新窘境是如何处理数据库。我是为测试环境创建一个还是为生产环境创建一个？我目前只有两个环境都使用的那个，让我的测试数据就在那里。我觉得我应该有两个，但我确信我的生产数据库的外观和感觉与我的测试数据完全相同。
有关哪条路的想法？而且，如果你认为后者，最好的方法是保持两个数据库相同（当然除了数据......）？
答案 0 :(得分：18)
每个环境都应该有一个单独的数据库。编写所有数据库对象（表，视图，过程等）并将脚本存储在源代码管理中。这些脚本首先应用于开发数据库，然后升级到测试（QA，UAT等），然后生成。通过将相同的脚本应用于每个数据库，它们最终都应该是相同的。
如果您有需要加载的数据（代码表，查找值等），则将数据加载的脚本作为数据库创建过程的一部分。
通过编写所有内容并将其保留在源代码管理中，可以随时为任何给定的构建级别重新创建数据库结构。
答案 1 :(得分：4)
你绝对应该有两个。至于保持它们同步，您应该始终创建用于创建数据库对象的DDL。像处理PHP代码一样处理这些脚本 - 将它们保存在版本控制中。每当您必须修改测试数据库时，请创建一个脚本来执行此操作，然后将其签入。然后，您可以在准备好后将这些更改传播到生产系统。
答案 2 :(得分：2)
每个开发工作站至少有一个数据库，一个用于生产。除此之外，您应该有一个用于测试环境，除非您只是一个开发人员并且具有与生产环境类似的设置。
答案 3 :(得分：1)
另见
How do you version your database schema?
这是一个常见问题，已被多次提问和回答。
Thomas Owens：复制不适用于版本化模式 - 它用于复制数据。你永远不想从dev复制到生产，反之亦然。
答案 4 :(得分：0)
一旦我部署了数据库，对我的开发数据库所做的任何更改都是在SQL脚本（而不是工具）中完成的，脚本会被保存并编号。
deploy.001.description.sql
deploy.002.description.sql
deploy.003.description.sql
... etc..
然后我在部署时按顺序运行每个脚本。
然后我将它们存档到一个名为
的目录中\deploy.YYMMDD\
从头开始。
如果我犯了错误，我永远不会回到之前的部署脚本，我将创建一个新脚本并将我的修复程序放在那里。
祝你好运答案 5 :(得分：0)
我一直在使用的一件事是创建一个安装了数据库的VM。您可以将VM保存为播放文件，包括其数据。你可以做的是拍摄播放文件的快照，然后根据需要启动多个不同的虚拟机。它们都可以是相同的，或者您可以修改一个或另一个。这是件好事：假设您有一个想要出去的数据库的开发版本，您只需在生产服务器而不是当前服务器上启动该虚拟机。
如果您的开发机器上没有生产数据，那么完全是另一个问题。在这种情况下，您可以做的一件事是设置跟踪VM。从主数据库运行复制到跟踪VM。当您到达需要在生产数据库上运行某些更改的位置时，首先停止从属并保存快照。
启动该快照的实例，完全退出从属模式，应用更改，并将QA框指向该数据库。如果它按预期工作，您可以针对主生产数据库运行修补程序。如果没有，请调出快照，然后再次从主服务器上复制快照，直到您准备重复更新测试为止。
答案 6 :(得分：0)
我有同样的困境。我一直认为production db与development db之间存在明显的二分法。它们是硬币的两面，而不是两个人会相遇。
当我停止使用“要么 production db 或 development db”来使我的应用程序“思考”时，很多问题都消失了。相反，我的应用程序使用local db。
当它在我的虚拟（dev）机器上运行时，该本地数据库恰好是dev db。我的应用程序虽然没有真正“知道”。
因此，对于主要部分，问题消失了。
但有时我想使用实时数据运行测试，或者将数据从代码移动到实时生产数据库中并快速查看结果。
这时我添加了live-read-only db connection的概念。该应用程序以不同方式对待它。它有点像您的应用程序如何对待像Google Apps这样的Web服务。它是“您的应用使用的一些外部资源”。
默认情况下，我的应用使用local db，在某些非常特殊的情况下（在测试套件中），它也会使用live-readonly db。 （因为它是一个只读连接，我不担心在测试期间弄乱实时数据）。
所以我的应用不是问“dev db 或 production db”这个问题，而是问“local db 或 {{ 1}}”。
显然我的情况可能与你的不同，但我发现这种“理解上的突破”对我最有帮助。