我使用 SQL Developer 的 GUI 进行 DDL 更改。问题是，我需要将这些相同的更改应用于测试环境。我想知道其他人如何处理这个问题。目前我不得不手动编写 ALTER 语句以使测试环境与开发环境保持一致，但这很容易出错(两次执行相同的操作)。在测试环境中没有重要数据的情况下，我通常会把所有东西都扔掉，从开发中导出 DDL 脚本并在测试中从头开始运行它们。
我知道有一些触发器可以存储每个 DDL 更改，但这是一个高度共享的环境，我希望尽可能避免这种情况。
也许我应该手动编写 DDL 东西而不是使用 GUI？
最佳答案
我已经看到了一种我不知道有多少种方法来尝试处理这个问题，最后我认为您只需要维护手动脚本。
现在，您不必自己编写。在 MSSQL 中，当您进行更改时，有一个生成脚本的小按钮，它会为您所做的更改吐出一个 SQL 脚本。我知道您在谈论 Oracle，我已经有几年没有使用他们的 GUI 了，但我只能想象他们具有相同的功能。
但是，您无法避免手动使用脚本。您将遇到很多关于预先存在的数据的问题，例如新列的默认值或如何处理重命名/删除/移动列的数据。这只是您无法摆脱的随着时间的推移使用数据库模式的分析的一部分。如果您尝试使用完全自动化的解决方案来执行此操作，您的数据迟早会变得一团糟。
为了让您的生活更轻松一些，我要推荐的一件事是确保将模式更改与代码更改分开。不同之处在于，对表和列的架构更改必须恰好运行一次并且永远不会再次运行，因此必须作为单独的更改脚本进行版本控制。然而，代码更改，如存储过程、函数甚至 View ，可以(并且应该)反复运行，并且可以像任何其他代码文件一样进行版本控制。我见过的最好的方法是当我们在 VSS 中拥有所有的 procs/functions/views 时，我们的构建过程将删除所有并在每次更新期间重新创建它们。这与重建 C#/Java/任何代码的想法相同，因为它确保一切始终是最新的。
关于sql - 我应该如何将 DDL 更改从一个环境迁移到另一个环境？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2404540/