假设有3个数据库
据我所知，Staging数据库需要与Production数据库同步 但是，
当我们开发时，我们可以通过 Dev 数据库和更改架构做任何我们想做的事情。 鸡肉和鸡肉现在来了鸡蛋问题。
要在暂存中测试，需要根据Dev数据库中所做的更改来更改暂存数据库架构。但是Staging数据库需要与Production同步。
你们是如何解决这个问题的？
答案 0 :(得分：9)
您需要将所有对dev数据库的更改写为以特定顺序运行的SQL迁移脚本。除非脚本位于脚本中，否则请勿更改数据库结构。不要更新，插入或删除任何行，除非它在脚本中。
理想情况下，有一种方法可以跟踪针对您找到的任何数据库版本运行的脚本。
然后您可以按如下方式更新阶段。
一切正常后......
答案 1 :(得分：5)
暂存需要与生产保持同步，直到您部署新更改为止。
那或称为第四个环境，称为Test，其中验证了新的升级。我们称之为UAT / Test，它通常是Staging服务器上的第二个数据库。
精确的方法取决于您如何保持同步。你真的在使用复制吗？或者只是Prod to Stage的备份/恢复？
答案 2 :(得分：1)
“临时数据库需要与生产同步”不成真。
生产模式（“设计”）与分段模式同步。分期首先出现，生产如下。
有时人们将生产数据下移到分期以帮助测试，但这可能很危险，具体取决于您的行业。
分期是“纯粹的”。
通过将实际数据放入纯分段模式，从分段构建生产。
有些人做的是有两个数据库。
今天＃1是生产，＃2是分期。
明天我们计划对架构进行更改。我们将＃2升级为新设计。然后我们将数据从＃1移动到＃2。
然后，当我们完成移动数据时，我们将应用软件切换为使用＃2作为生产。
我们以＃2作为产品运行，直到下一次更改为止。
答案 3 :(得分：1)
我们仅使用登台数据库来测试我们的部署机制。它与生产相匹配。
我们在开发中创建更改并定期将其部署到QA。一旦我们准备好投入生产，我们会将所有更改汇总到一个发布包中。该发布包首先在登台时进行测试，然后如果没有部署问题则将其推送到生产阶段。
答案 4 :(得分：1)
如果您有能力添加测试环境，您可能需要考虑这一点。
否则你基本上需要在dev环境中进行测试。在您对发布版本有足够信心的情况下，您可以在暂存环境中更改架构。进行频繁的备份并进行良好的回滚过程，以便在将架构更改推送到暂存时出现问题时，您可以随时回滚。
此外，用于比较数据库架构的好工具是SqlCompare。在推送架构更改之前，您应该始终使用类似的东西。