I have the following scenario. Vendor has a database with table having some vendor-provided data inserted. Customers have a copy of the database with ability to add new rows to the same table, but they should not delete some vendor-provided records. Periodically vendor sends patches/updates with additional records to be added to the same table. Someone can say that a better design will be to store vendor and customer data in separate tables, but the structure of both types of records is identical and for application is simpler to have them in the same table. I’ve named the scenario "merge-like replication”- it does not use MS SQL Server Merge Replication, but use proprietary methods to deliver changes to customer databases.
Initially the table had an IDENTITY surrogate key, which is a common approach.
But it causes a lot of complexity in replication. In my scenario it obviously doesn’t work on customer copies of databases, that have different (and overlapping) identity values.
So I have to change IDENTITY primary key to GUID (see posts here and here) and it should do the work .
posted @ Thursday, August 03, 2006 9:31 AM