使用Oracle的数据库源控制 [英] Database source control with Oracle

问题描述

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

I have been looking during hours for a way to check in a database into source control. My first idea was a program for calculating database diffs and ask all the developers to imlement their changes as new diff scripts. Now, I find that if I can dump a database into a file I cound check it in and use it as just antother type of file.

主要条件是：

• 适用于Oracle 9R2


• 人类可读，所以我们可以使用diff来查看差异。 （.dmp文件似乎不可读）


• 批处理中的所有表。


• 它存储两个结构和数据


• 它支持CLOB和RAW类型。


• 它存储过程，包及其主体，函数，表，视图，索引，约束，隐藏和synonims。


• 它可以变成可执行脚本，将数据库重建到一个干净的机器。


• 不限于真正小型的数据库（支持至少200.000行）

• Works for Oracle 9R2
• Human readable so we can use diff to see the diferences. (.dmp files doesn't seem readable)
• All tables in a batch. We have more than 200 tables.
• It stores BOTH STRUCTURE AND DATA
• It supports CLOB and RAW Types.
• It stores Procedures, Packages and its bodies, functions, tables, views, indexes, contraints, Secuences and synonims.
• It can be turned into an executable script to rebuild the database into a clean machine.
• Not limitated to really small databases (Supports least 200.000 rows)

。我已下载了很多演示，但确实以某种方式失败。

It is not easy. I have downloaded a lot of demos that does fail in one way or another.

编辑：我不介意替代aproaches，允许我们在批处理模式下检查对我们的发布数据库结构和对象+数据的工作系统。

EDIT: I wouldn't mind alternatives aproaches provided that they allows us to check a working system against our release DATABASE STRUCTURE AND OBJECTS + DATA in a batch mode.

顺便说一句。我们的项目已经开发了多年。

By the way. Our project has been developed for years. Some aproaches can be easily implemented when you make a fresh start but seem hard at this point.

EDIT ：为了更好地理解问题，让我们说一下一些用户有时可以改变生产环境中的配置数据。或者，开发人员可能会在realease分支中创建新字段或更改视图，而不通知。我需要知道这种变化，或者将变更合并到生产中会很复杂。

EDIT: To understand better the problem let's say that some users can sometimes do changes to the config data in the production eviroment. Or developers might create a new field or alter a view without notice in the realease branch. I need to be aware of this changes or it will be complicated to merge the changes into production.

推荐答案

这么多人试图做这种事情（差异模式）。我的意见是

So many people try to do this sort of thing (diff schemas). My opinion is

• 源代码进入版本控制工具（Subversion，CSV，GIT，Perforce ...）。把它看成是Java或C代码，它真的没有什么不同。您应该有一个安装过程，将其检出并将其应用到数据库。


• DDL是源代码。它也进入版本控制工具。


• 数据是一个灰色区域 - 查找表可能应该在版本控制工具中。应用程序生成的数据当然不应该。

我现在的做法是创建类似于Ruby on Rails迁移的迁移脚本。将DDL放入脚本并运行它们以在不同版本之间移动数据库。将发布内容组更改为单个文件或一组文件。然后你有一个脚本将你的应用程序从版本x移动到版本y。

The way I do things these days is to create migration scripts similar to Ruby on Rails migrations. Put your DDL into scripts and run them to move the database between versions. Group changes for a release into a single file or set of files. Then you have a script that moves your application from version x to version y.

我从来没有做过一件事（我曾经做过，直到我学得更好）是使用任何GUI工具在我的开发环境中创建数据库对象。从第1天写DDL脚本 - 你需要他们无论如何促进代码测试，生产等。我见过这么多人使用GUI来创建所有的对象，并发布时间有一个拼字，试图生产脚本来正确创建/迁移经常没有测试和失败的模式！

One thing I never ever do anymore (and I used to do it until I learned better) is use any GUI tools to create database objects in my development environment. Write the DDL scripts from day 1 - you will need them anyway to promote the code to test, production etc. I have seen so many people who use the GUIs to create all the objects and come release time there is a scrabble to attempt to produce scripts to create/migrate the schema correctly that are often not tested and fail!

每个人都有自己的偏好，如何做到这一点，但我看到了很多它做了不好的多年来形成我的意见上面。

Everyone will have their own preference to how to do this, but I have seen a lot of it done badly over the years which formed my opinions above.

这篇关于使用Oracle的数据库源控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！