Re: How to propagate change from one database to another database

From: Robert Eskridge <bryny_at_dfweahs.net>
Date: Thu, 25 May 2000 16:43:05 -0500
Message-Id: <10508.106782@fatcity.com>

Guang,

Thursday, May 25, 2000, 4:55:05 PM, you wrote:

G> Hi:

G> I am looking for suggestions and advice on how to move data from one oracle G> database to another on daily basis.

G> We have a production oracle db (let's call it "prod") on a unix box that 
G> runs 7x24. It supports a web front end application for shopping. Most of the 
G> data in the database will be loaded into memory of an application server 
G> when the application starts.

G> We also need to provide the capability for people in the shop to change data 
G> in the database. They do not want to change the data in "prod" instance 
G> directly. They want to set up a separate unix box and have a copy of "prod" 
G> running (let's call it "prod_mirror"). They would like to make changes on 
G> "prod_mirror", QA the change and then propagate all the changes in 

G> "prod_mirror" to the "prod" instance. The changes involve about 10 tables G> (product, price, catalog, etc).

I think you are trying to shoehorn functionality into an inadequately designed application by using another copy of the database. In the long run I think you'll be much happier with a modification to the application.

I would suggest changing the application where it never edits production tables. Instead the application should copy the appropriate rows from the production table to staging tables, allow the edits there, then after editorial review move the rows back into production at a specified time.

In this approach you are only keeping spare copies of the items of interest in another table for a short period of time. This is self contained in one database. Thus you don't double up on all your resources just to get around this design flaw. Received on Thu May 25 2000 - 16:43:05 CDT