External read-only DB, my local DB, inconsistency

There's a service A that works with DB1, there's service B that works with DB1 and DB2. Service A has read-write access to DB1 and doesn't work with DB2 at all. Service 2 has read-write access to DB2 and read-only access to DB1.

The idea is, I'm developing service 2 and concerned about the inconsistency. Service 2 is like a "plugin" 开发者_运维知识库to service 1, so DB2 may be thought of as "some more data related with DB1 entities". There's no way I can explicitly synchronize with Service 1 and it's DB, there's no way I can receive any notifications when entities are removed, changed or new entities appear.

The question is, what's the right approach for service 2 to make all this stuff consistent?

I'm thinking about scheduling copying of entities from DB1 to DB2, so the only thing that really works with DB1 is that "copier". Then, Service 2 will only work with DB2 and there should be no problems. This seems to be quite trivial, so I really like this approach.

Any other ideas?

Some more details: DB1 is like 2 tables with summary of 1M rows. Both DBs are on the same server. The server is MS SQL 2005/2008. Service 2 is in .NET.

The "periodic copy" option is a good idea, and will work well if your requirements can handle a bit of a lag between when a record is added / updated in DB1 vs. when it shows up in DB2.

If your application can't handle that lag, then the approach I would take is essentially a 2-pronged method where you still do the periodic sync from DB1 to DB2, but then also have your application copy over data from DB1 into DB2 if it finds that something it needs in DB2 isn't there yet.

For example, say you have a user that needs to update some special profile information that is stored in DB2 (a common "plugin" scenario).

1. When the user goes into your plugin's portion of the application to set this special bit of information, your app will first look for that user in DB2.
2. If the user's info isn't in there yet (a new user, for example),
   • then you go to DB1 to get the data and populate it into DB2.
3. You can then procede with saving the special profile information as you normally would.

Depending on the performance requirements you have, the "copy as needed" method may be enough on it's own and may not need an additional "sync everything" periodic process. Having the extra sync process, however, may reduce the number of "misses" your application will have on DB2 if it looks for information that isn't there and has to fetch it from DB1.