Question

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

主要条件是：

适用于Oracle 9R2
人类可读，所以我们可以使用diff来查看差异。（.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来创建所有对象并且发布时间有一个拼字游戏试图生成用于正确创建/迁移模式的脚本，这些脚本通常没有经过测试而失败！

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

Answer 2

Oracle SQL Developer具有“数据库导出”功能。它可以生成包含所有DDL和数据的单个文件。

Answer 3

我将PL / SQL开发人员与VCS插件集成到Team Foundation Server中，但它只支持数据库对象，而不支持数据本身，这通常不会被源代码控制。

以下是链接：http://www.allroundautomations.com/bodyplsqldev.html

Answer 4

它可能不像检测差异一样光滑，但我们使用简单的ant构建文件。在我们当前的CVS分支中，我们将“基础”数据库代码分解为表和触发器等的ddl。我们还将以相同的方式分解delta文件夹。从头开始，您可以运行“base”+“delta”并获取数据库的当前状态。当你去生产时，你只需要运行“delta”构建并完成。如果你有一个庞大的架构并且你正在迅速改变它，那么这个模型不能很好地工作。（注意：至少在表，索引等数据库对象中。对于包，过程，函数和触发器，它运行良好。）以下是一个示例ant任务：

    <target name="buildTables" description="Build Tables with primary keys and sequences">
<sql driver="${conn.jdbc.driver}" password="${conn.user.password}"
    url="${conn.jdbc.url}" userid="${conn.user.name}"
    classpath="${app.base}/lib/${jdbc.jar.name}">
    <fileset dir="${db.dir}/ddl">
        <include name="*.sql"/>
    </fileset>
</sql>
</target>

Answer 5

我认为这是一个例子，

您正在尝试解决问题
你想出了一个解决方案
您不知道如何实施解决方案
现在您正在寻求有关如何实施解决方案的帮助

获得帮助的更好方式

告诉我们问题是什么
寻求解决问题的想法
选择最佳解决方案

我不知道你要解决的问题是什么。有时从问题中可以明显看出，这个肯定不是。但我可以告诉你，这个“解决方案”将变成自己的维护噩梦。如果您认为开发数据库和使用它的应用程序很难。这种以人类可读形式对整个数据库进行版本化的想法简直就是疯了。

Answer 6

你试过Oracle's Workspace Manager吗？并不是说我在生产数据库中有过任何经验，但我发现了一些有希望的玩具实验。

Answer 7

不要试图区分数据。只需编写一个触发器来存储数据更改时您想要获取的内容。

Answer 8

尽管可能很贵，但像TOAD for Oracle这样的工具可以解决这类问题。

尽管如此，我首选的解决方案是以所有DDL（包括存储过程定义）作为文本开始，在版本控制下进行管理，并编写将从源创建功能正常的数据库的脚本。如果有人想要修改模式，他们必须必须将这些更改提交到存储库，而不仅仅是直接修改数据库。没有例外！这样，如果您需要构建反映版本之间更新的脚本，则需要采取所有已提交的更改，然后添加所需的任何DML来按摩任何现有数据以满足更改（为新列添加默认值）现有的行等。）将所有DDL（和预填充数据）作为文本，收集差异就像区分两个源树一样简单。

在我上一份工作中，我有NAnt脚本可以恢复测试数据库，根据数据库的版本运行所需的所有升级脚本，然后将最终结果转储到DDL和DML。我会对一个空数据库（从头创建一个）做同样的事情，然后比较结果。如果两者显着不同（转储程序不完美），我可以立即告知需要对更新/创建DDL和DML进行哪些更改。虽然我确实使用了像TOAD这样的数据库比较工具，但是当我需要生成用于按摩数据的通用脚本时，它们没有手写SQL那么有用。（机器生成的代码可能非常脆弱。）

Answer 9

尝试RedGate的Source Control for Oracle。我从未尝试过Oracle版本，但MSSQL版本非常棒。

Oracle的数据库源代码控制

9 个答案: