Oracle与Subversion的集成

Question

我正在管理一个基于Java、Subversion和SVN的基于Web的项目，有8个开发人员。不幸的是，对于该项目来说，处理数据库更改是一个很大的问题。在我们的情况下，每个用户都可以更新表格，但却忘记了将更改脚本放入SVN中。因此，我们花费了大量时间来查看和调试由于未更新的表格或视图引起的问题。

因此，我想知道是否有任何方法、工具或插件可以将所有DB更改保存为脚本，例如在SVN上？

编辑1：从整个数据库中获取转储并不能解决我的问题，因为在真实环境中，我不能丢弃客户数据并返回到新的转储。

- TonySalimi

---

在我们的情况下，每个用户都可能更新表格并忘记将更改脚本放入svn。这是你的问题。你只需要更好的变更管理程序。人们必须提交更改，这是系统运作的唯一方式。如果人们没有提交更改，那么问题就出在管理情况上，而不是你使用的工具。 - Ben

@Ben - 像你一样，我不认为这是我的工具的问题。我有一个问题，我认为它可以通过自动生成更改脚本来解决。因此，如果你有任何更好的解决方案，可以告诉我。另外，请你提出一个更好的变更管理程序来适应我们的情况吗？ - TonySalimi

很不幸，我并没有解决方案，这就是为什么我发表了评论而不是答案。我和其他人一样依赖于你和他们提交的更改。唯一的区别是，在我的工作场所，人们确实会提交他们的更改，如果他们不这样做，通常会被发现，因为他们造成的问题非常明显。我目前的问题（总会有问题），就是烂提交信息 :-)。 - Ben

Answer 1

我认为这正是您需要的。一个开源的数据库变更管理系统。Liquibase。 http://www.liquibase.org/

- Horse Voice

Answer 2

不要存储更改脚本，只存储删除并重新创建所有对象的脚本。开发人员应该在本地实例上更改和运行这些脚本，运行自动化单元测试，然后提交他们的更改。

从头开始重建比不断运行修改脚本要好得多。除非每个人都可以轻松地从头重新构建整个系统，否则您永远无法控制您的应用程序。

（我假设您正在询问有关主干开发的问题，其中有许多小更改。对于重大升级，例如从版本1.1移动到版本1.2，您仍需要使用更改脚本来帮助保留数据。）

- Jon Heller

---

我说的是将版本从1.1移动到1.2。我如何确保所有更改脚本都存储在某个地方？我可以如何保证存储的更改脚本可以完全升级我的数据库到1.2版本？ - TonySalimi

Answer 3

维护数据库变更有两个方面。一方面，正如您所提到的，可以通过脚本的形式应用于旧模式以进行升级。然而，这只是部分答案，因为开发人员很难查看脚本、解析它们并弄清楚最近的模式更改如何影响他们的工作。

因此，除了更改脚本之外，我建议您还要在文本文件中检查可读性较高的数据库元数据。SchemaCrawler 是一个免费的工具，专门设计用于此目的，并以可比较的格式生成丰富的元数据信息。我发现，如果您将模式元数据的自动检入过程定为每晚执行一次，则随着时间的推移，数据库元数据的更改变得可追溯。

- Sualeh Fatehi

---

MerC Agha Sualeh！我很好奇你的工具是如何检测列重命名的？难道真的需要删除并重新插入该列吗？ - TonySalimi

列重命名可能会带来问题，需要使用变更管理工具进行管理。http://www.liquibase.org/manual/rename_column - Sualeh Fatehi

Answer 4

根据Oracle：仅导出架构主题，比Liquibase更便宜但质量更差的解决方案可能是 后提交挂钩，其中

• expdp ... DUMPFILE=file.dmp CONTENT=METADATA_ONLY 到 WC或存储库中的特殊位置的dir
• 提交此 file.dmp

- Lazy Badger

---

但我不需要转储文件。我需要变更脚本以将数据库从一个版本迁移到另一个版本。 - TonySalimi

那是我们现在正在做的事情。真的很令人沮丧。:--( - TonySalimi

Answer 5

请尝试使用这个工具：www.dbapply.com 它既有图形用户界面，可以手动部署来自Subversion存储库的脚本，也有命令行接口，支持持续集成。

支持Subversion分支。

可在Windows和Linux上运行（需要JRE 8）。

- Anton