使用 Oracle 进行数据库源代码控制

Question

几个小时以来，我一直在寻找一种将数据库 checkin 源代码管理的方法。我的第一个想法是一个计算数据库差异的程序，并要求所有开发人员将他们的更改作为新的差异脚本来实现。现在，我发现如果我可以将数据库转储到文件中，我可以将其 checkin 并将其用作另一种类型的文件。

主要条件是:

• 适用于 Oracle 9R2
• 人类可读，因此我们可以使用 diff 来查看差异。 (.dmp 文件似乎不可读)
• 一个批处理中的所有表。我们有 200 多张 table 。
• 它存储结构和数据
• 它支持 CLOB 和 RAW 类型。
• 它存储过程、包及其主体、函数、表、 View 、索引、约束、序列和同义词。
• 它可以变成一个可执行脚本，将数据库重建成一台干净的机器。
• 不限于非常小的数据库(支持至少 200.000 行)

这并不容易。我下载了很多确实以某种方式失败的演示。

编辑:我不介意其他方法，前提是它们允许我们以批处理模式根据我们发布的数据库结构和对象 + 数据检查工作系统。

顺便说一下。我们的项目已经开发多年。有些方法在您重新开始时可以很容易地实现，但在这一点上似乎很难。

编辑:为了更好地理解问题，假设某些用户有时可以更改生产环境中的配置数据。或者开发人员可能会在 realease 分支中创建一个新字段或更改一个 View ，恕不另行通知。我需要知道这些变化，否则将这些变化合并到生产中会很复杂。

Answer 1

很多人尝试做这种事情(差异模式)。我的意见是

• 源代码进入版本控制工具(Subversion、CSV、GIT、Perforce ...)。就好像它是 Java 或 C 代码一样对待它，它真的没有什么不同。您应该有一个安装过程来检查它并将其应用于数据库。
• DDL 是源代码。它也进入版本控制工具。
• 数据是一个灰色区域 - 查找表可能应该在版本控制工具中。应用程序生成的数据当然不应该。

最近我做事的方式是创建类似于 Ruby on Rails 迁移的迁移脚本。将您的 DDL 放入脚本并运行它们以在版本之间移动数据库。将发布的更改分组到单个文件或一组文件中。然后你有一个脚本将你的应用程序从版本 x 移动到版本 y。

有一件事我再也没有做过(在我学得更好之前我曾经做过)是使用任何 GUI 工具在我的开发环境中创建数据库对象。从第一天起就编写 DDL 脚本——无论如何你都需要它们来将代码提升到测试、生产等阶段。我见过很多人使用 GUI 创建所有对象并在发布时出现拼字游戏来尝试生产用于正确创建/迁移架构的脚本通常未经测试且失败!

每个人都会对如何做到这一点有自己的偏好，但多年来我看到很多做得不好，形成了以上观点。