Question

I am just getting started breaking a .NET application and its SQL Server database into two systems - an intranet and a public website.

The various database tables will need to be synchronised between the two databases in different ways, for example:

Moving from web to intranet, with the intranet data becoming read-only
Moving from intranet to web, with the web data becoming read-only
Tables that need to be synchronised and are read/write on both the intranet and web databases.

Some of the synchronisation needs to occur relatively quickly with minimal lag, possibly with some type of transaction locking to ensure repeatable reads etc. Other times it doesn t matter if there is a delay between synchronisation.

I am not quite sure where to start with all this, as there seems to be many different ways of achieving this. Which technologies and strategies should I be looking at?

Any tips?

Answer 1

A system like that looks like the components are fairly tightly coupled. An upgrade across several systems all at once can turn into quite the nightmare.

It looks like this is less of a replication problem and more of a problem of how to maintain a constant connection to a remote database without much I/O lag. While it can be done, probably isn t going to work out very well in terms of scalability and being able to troubleshoot problems.

You might look at using some message queueing and asynchronous data processing from the remote site to the intranet. You ll probably have to adjust some expectations of the business side so that they don t assume that everything is accessible real-time all the time.

Of course, its hard to give specifics without more details. It might be a good idea to look into principles of SOA and messaging systems for what you re trying to do.

Answer 2

Out of the box you have SQL Server Replication. Sounds like a pair of filtered transactional replication publications can do the job. Transactional replication has a low overhead on the publisher and can ensure transactional consistency of the published changes.

Nathan raises some very valid points about the need for a more loosely coupled solution. Service Broker can fit that shoe quite well with its loosely coupled asynchronous nature, and provide a headache free upgrade future since SSB is compatible between SQL Server versions and editions. But this freedom comes at the cost of letting the heavy lifting of actually detecting the changes and applying them to the tables to you, as application code, not a trivial feats.

友情链接