在软件开发中，它会经历一系列阶段——Dev、Test、UAT、Staging、Demo 和 Production。
这是我通过互联网阅读/研究后认为是正确的。
数据库开发
- 在单独的数据库中开发数据库（与产品版本相同，仅使用测试数据）
- 测试开发数据库（与产品版本相同，仅使用测试数据）
- 推广到产品数据库
我的问题是：
- 我在上述数据库开发阶段是否正确？
- 数据库开发中是否有等效的 UAT/Staging/Demo？
- 如果第 1 点是正确的，人们如何在开发/测试数据库上创建/工作并最终将其推送到产品数据库？
PS：我是数据库新手，所以请放轻松！谢谢！
对于数据库开发，您可以选择尽可能多地使用通常用于应用程序软件开发的相同环境。大多数人可能没有您上面列出的所有六个独立环境（即使是常规的应用程序软件开发），但至少有一个 DEV、STAGING 和 PROD 环境是很常见的。有些人也选择配置 UAT 环境。
这或多或少是正确的。我要更正的唯一一点是 DEV 中的版本总是大于或等于 PROD 中的版本。自然，如果开发人员对 DEV 中的数据库进行更改，它现在是比 PROD 数据库更新的版本。当然，可以在 DEV 中撤消该更改，但 DEV 绝不应该是比 PROD 更旧的版本，只是因为更改应该首先在 DEV 中进行，然后部署到任何中间环境，最后部署到 PROD。
是的，这些是等价的。如果您在部署工作流程中决定它们，那么其中任何一个都是可接受的环境。
有多种方法可以手动和自动管理环境之间的部署和刷新。这仅取决于您的业务需求和您使用的数据库系统。
目前我支持 DEV、STAGING 和 PROD 环境。我的工作流程是在 DEV 中进行更改并跟踪我更改了哪些对象。当我准备好将当前版本的 DEV 升级到 STAGING 时，我运行一组脚本，从 PROD 数据库的最新备份中刷新 STAGING。这些脚本还进行适当的数据混淆和特定于 STAGING 环境的更改。（这些脚本都是我创建的数据库作业的一部分，因此我只需按一个按钮即可从 PROD 刷新 STAGING。）
从 PROD 刷新 STAGING 后，我使用模式迁移工具（称为 SQL Examiner）比较 DEV 和 STAGING 数据库的差异，并自动生成从 DEV 到 STAGING 的迁移脚本。
然后，我在我的 STAGING 环境中运行这些脚本，并将相关的 STAGING 应用程序交给适当的用户进行测试。一旦他们接受更改已准备好 PROD，我将这些脚本锁定在源代码控制中，以便它们为我们部署到 PROD 的那一天做好准备。此时，可以在 DEV 中进行进一步的更改，而不必担心它们与准备好用于 PROD 的锁定版本发生冲突。它们都将成为未来候选版本的一部分。
然后，当需要部署到 PROD 时，我们以与在 STAGING 环境中运行的相同方式运行完全相同的脚本。现在 PROD从 DEV赶上了那个版本。
所有这一切的关键是 STAGING 环境，它是 DEV 和 PROD 之间的握手。它可以以最少的护理从任一方向进行更新。它通过来自 PROD 环境的刷新和/或来自 DEV 环境的部署来持续维护。这创建了一个良好的工作流程，可确保在所有环境中进行正确的版本迁移和测试。
附带说明：有一种说法，GUI 变化最多，业务逻辑次之，数据库变化最少。
这意味着许多数据库使用“过时”的技术（与例如前端相比），它也可以解释为什么组织/流程没有那么好和彻底定义。
随着现代数据存储行业的专业化，这可能已经改变，现在真的只是一个（旧的）“模因”。