Design Requirements for Replication

Data replication is a complex technology, and Microsoft® SQL Server™ replication recognizes that there cannot be a single solution that is right for all applications. SQL Server provides a variety of replication technologies that can be tailored to your application’s specific requirements. Each technology produces different benefits and restrictions, depending on your requirements, across three important dimensions:

Your requirements along and across these three dimensions will vary from one distributed application to the next. It is also quite likely that requirements on one dimension will conflict with another dimension. For example, it is commonly accepted that an application must use the two-phase commit (2PC) update protocol (or a related protocol like three-phase commit) to guarantee full data consistency and atomicity without conflicts when modifying the same data at multiple locations. However, one requirement for 2PC is fully available and reliable communication between all participating sites. This makes the use of 2PC inappropriate for many distributed applications because not all sites can be “well-connected” to each other.

For example, contrast the requirements for a distributed application supporting a company’s sales force with a distributed application supporting the same company’s accounts receivable department. Both applications use replication for distributing data. However, the company’s traveling sales force can take customer orders on laptop computers that are disconnected from the central office network. The lack of a network connection (and an accurate report of inventory) must not prevent sales representatives from taking and submitting the order. Thus, the need for autonomy in the sales application outweighs the risk of taking orders for out-of-stock items (that is, back orders are allowed). In contrast, the invoices sent out by the accounts receivable department must be completely accurate and current for auditing purposes. Thus, the need for data consistency outweighs the need for employee autonomy.

You can maintain both data consistency and autonomy if you partition your application. For example, if each site or sales representative takes orders for totally separate products, all sites can work autonomously. And, because each works with different data, there will not be conflicting changes that compromise data consistency.

See Also
Transaction Processing vs. Decision Support Transactions

  


(c) 1988-98 Microsoft Corporation. All Rights Reserved.