views:

300

answers:

3

Here's my problem at a high level:

We have two business applications. App1 inputs and stores a large set of data. We need something that will transfer data from App1 to App2 whenever any relevent data in App1 has changed. Essentially we want the data in App2 to be synchronized from App1, except that App2 contains a subset of the data.

App1 uses a SQL Server 2000 database.

App2 uses a SQL Server 2005 database.

So, for example, if a user is using App1 and they update some data, that data needs to get saved to the App1 database and then sent to the App2 database, as realtime as possible.

Looking for some good ideas that won't bring either system to its knees.

+2  A: 

Have you considered replication?

Michael Sharek
I hadn't considered that, but I will look into it. Thanks for the suggestion!
MrDustpan
A: 

Are they in different physical locations? Why can't you use a single database and only allow app2 to access the subset of data that it is allowed to?

Echo
Great questions!Are they in different physical locations? Yes.Why not use a single database? Because we will infact have multiple App1 applications (and databases) whose data will all be combined and used by a single App2 application.
MrDustpan
+1  A: 

Presumably you could state this as "When an event of interest occurs in System A, invoke Action B to asynchronously (i.e. decoupled) update System C."

Sounds like a message queue - either formally, or in a database table.

Some might think "trigger", but there's a deadly synchronous dependency there. But a trigger could feed the queue.

le dorfier
I think you're exactly right - I keep thinking of the Observer pattern, where the database for App1 is the subject, and App2 is the observer. And a message queue seemed like an obvious way to implement that. Also, I like your suggestion of using triggers to feed the queue. Thanks!
MrDustpan