Oracle的数据库源代码控制

Question

我一直在寻找一种方法来检查数据库中的源代码控制.我的第一个想法是计算数据库差异的程序,并要求所有开发人员将他们的更改作为新的差异脚本.现在,我发现如果我可以将数据库转储到文件中,我可以检查它并将其用作另一种类型的文件.

主要条件是:

• 适用于Oracle 9R2
• 人类可读,所以我们可以使用差异来看待差异.(.dmp文件似乎不可读)
• 批处理中的所有表.我们有200多张桌子.
• 它存储两种结构和数据
• 它支持CLOB和RAW类型.
• 它存储过程,包及其主体,函数,表,视图,索引,约束,Secuences和synonims.
• 它可以转换为可执行脚本,以将数据库重建为干净的机器.
• 不限于真正的小型数据库(支持至少200.000行)

这不简单.我已经下载了很多以这种或那种方式失败的演示.

编辑:我不介意替代方法,只要它们允许我们以批处理模式检查我们的发布数据库结构和对象+数据的工作系统.

顺便说说.我们的项目已经开发多年.当你重新开始时,一些方法很容易实现,但在这一点上看起来很难.

编辑:为了更好地理解问题,我们可以说有些用户有时会对生产环境中的配置数据进行更改.或者开发人员可能会在realease分支中创建新字段或更改视图,而不会发出通知.我需要知道这些变化,或者将变更合并到生产中会很复杂.

Answer 1

很多人都试图做这种事(diff schemas).我的意见是

• 源代码进入版本控制工具(Subversion,CSV,GIT,Perforce ...).把它看作是Java或C代码,它真的没什么不同.您应该有一个安装过程将其检出并将其应用于数据库.
• DDL是源代码.它也进入了版本控制工具.
• 数据是一个灰色区域 - 查找表可能应该在版本控制工具中.应用程序生成的数据肯定不应该

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

我从未做过的一件事(我以前做过,直到我学到更好)是使用任何GUI工具在我的开发环境中创建数据库对象.从第1天开始编写DDL脚本 - 无论如何你都需要它们来推广代码以进行测试,生产等.我见过很多人使用GUI来创建所有对象并且发布时间有一个拼字游戏试图生成用于正确创建/迁移模式的脚本,这些脚本通常未经过测试而失败!

每个人都会对如何做到这一点有自己的偏好,但多年来我已经看到很多事情已经形成了我的意见.