Re: How to CM an Oracle DB

In article <34517137.76D2_at_doubled.com>, Mark <mso_at_doubled.com> writes
>Hello,
>
>I have been doing CM for over a year now. Recently, I have been put on a
>new project as the CM Manager. This project uses an Oracle DB and uses
>Oracle financials. Oracle Designer2000 and Developer2000 are used to
>work on/develop the DB.
>
>I have encountered two issues regarding the above:
>
>1) The politial issue is that the DBA and Oracle developers feel all CM
>should be concerned with is keeping track of the DB patches (which they
>maintain themselves in their environment). This scope of CM is not
>anywhere close to being acceptable. If CM is to manage (and be
>responsible for) the configuration of the system (in system test and in
>production), the database needs to be CM'd just like everything else,
>especially since its the heart of the system.
>
>2) The functional issue is that I do not know how to CM a DB. I cannot
>find any resourses that describe how a database should be CM'd. The
>books I have go into painful detail about SCM, but don't mention
>anything about databases.
>

I have been looking for a tool to support this for a while with no luck. There are two approaches.

[Quoted] [Quoted] Use a tool like ERWin to reverse engineer the database schema and version control the schema. This is not very granular, but given that you are working with a third party application this may be sufficient. If you are using Designer/2000 you could version control the application in Designer/2000.

Extract all the database objects as individual files of ddl (create table.., create procedure... etc) and version control these. This gives a much finer level of control and makes it easier to control multiple development teams.

The main drawbacks of this approach are

[Quoted]
1. that in order to change a table you need (at least) an alter table command whereas what a traditional vc system gives you is two different create table commands. [Quoted]
2. vc systems don't know anything about databases and give no help in [Quoted] maintaining dependency information.

[Quoted] I am afraid there is no easy answer.

-- 
Jim Smith