我们一直在生产数据库服务器上存储我们的临时数据库，其思路是尽可能与生产相同。
最近，一些评论让我质疑这个想法。由于我有可能错误地将某些东西用于生产，因此不要将它们放在同一台服务器上是有意义的。
我的Staging数据库是否真的与我的开发数据库位于同一台服务器上，而不是与生产相同的服务器？
答案 0 :(得分：7)
理想情况下，您希望拥有一个单独的暂存环境，镜像您的实时环境，但实际上并不存在。但是，$$$并不总是允许这样，因此并不总是遵循理想。
这包括（但不限于）以下内容：
这些机器（物理或虚拟）上的任何内容都应该在各自的环境中隔离，因此您不应该在生产服务器上看到登台代码，同样您也不应该在生产数据库服务器上看到登台数据库。它们应该是分开的。
此外，如果您在内部使用大量带宽，您可能甚至需要隔离网络，以防止暂存环境带宽使用使生产环境的带宽饱和。
答案 1 :(得分：3)
无论您最终选择哪种解决方案，我都会说：保留您的生产服务器进行生产和生产！
如果你把一些非生产放在上面，当然，正如你所说的那样，存在错误的风险......但是也存在错误的风险：如果你的应用程序发疯，并使用所有的CPU怎么办？例如，服务器？你的生产可能会受到影响。
当然这只是一个例子; - ）
在我看来，最好的解决方案是使用另一台服务器进行暂存，设置尽可能接近（一个真正的“克隆”将是最好的）到生产设置。
考虑到这对于仅由少数测试人员使用的机器而言可能花费相当多，但通常不可能:-（我看到的替代方案是使用虚拟机（托管在您的开发服务器上 - - 而不是制作一个）：它就像一个“真正的”机器，你可以随心所欲地做任何事情，而不会影响刺激和开发。
并且，如果需要，您可以使用多个虚拟机，如果需要，最接近您的生产设置。
答案 2 :(得分：3)
在我的书中，暂存环境应该是独立的，因为它允许您为新版本排练推出过程。如果您在同一个盒子或同一个虚拟机上，则无法获得库更新等的“完整”体验。
我个人喜欢虚拟机，因为我可以将生产恢复到舞台然后更新它。这意味着我的更新非常现实，因为正在复制所有边缘案例数据，库等。这是一件好事...我无法计算我们的主要产品的9年历史中未包含库模块的数量或数据库的某些更新脚本未在开发和测试环境。
就触及生产环境而言...如果有替代方案，我会说从不这样做。更新分段中的共享库也会影响生产，您会感到痛苦。更新代码并导致您的Web服务器陷入困境，并且（至少部分）您的实时环境已经关闭。
如果你必须伪造它，我建议与开发环境共享，并且只是意识到更新生产会在更新过程中导致意外停机，因为验证一切正常。出于预算原因，我们必须在最初几年内这样做，只要您不仅仅更新生产并离开，它就可以工作。
总结
答案 3 :(得分：2)
您的登台数据库永远不应与生产服务器位于同一服务器上。我说可以将它与你的开发服务器放在同一台服务器上。
有很多事情可能出错，
在错误的数据库上操作数据
做一些可能实际上
的事情关闭服务器。你可能需要
在重启期间重启数据库服务器 开发和测试。
作为一项规则，我不认为开发人员应该可以访问实时环境。只有操作才能访问。
答案 4 :(得分：2)
正如其他人所说，应该像瘟疫那样避免在生产环境中保留非生产实体。开发人员错误地添加或修改生产环境所依赖的内容的可能性太多。我们的生产服务器仅在部署期间进行修改我们跟踪每个已更改的文件，并建立适当的机制，以最小的努力回滚更改。
如果您无法获得专用硬件，请在您的开发环境中继续进行暂存。
答案 5 :(得分：1)
在生产服务器上安装临时数据库是有风险的。然而，在充分艰苦的调试/测试阶段，实际生产风险很小。如果对分段的负载最小，则尤其如此。
答案 6 :(得分：0)
如果您没有用于开发，暂存和生产的特定硬件，那么在开发SQL Server上安装Staging数据库是一种常见的解决方案。我
比在Production Server上安装Staging数据库，尝试对Staging Database执行某些操作以及关闭Production SQL Server更安全。