Since GUID has turned into chicken-egg arguments, wonder if anyone can really advise me on this issue:
Here's my scenario, a purchase order (PO) application:
We want to have a centralized database with remote sites connected to it.
Some of the sites are without connection, they will have their own servers with scheduled replication to the centralized database.
The schema design is something like this:
Each PO will have many revisions
Each revision will have many PO line items
Each PO line item will have many Delivery Schedules
In the past i used int IDENTITY as transaction ID in revision and line item tables.
transaction ID in revision table is FK to line item table, and transaction ID line item table is FK to Delivery Schedules table.
This work well in standalone database.
Now that we need to merge replicates, int IDENTITY produced in remote DB will conflict with IDENTITY produced in central DB.
I'm thinking of using GUID to replace int IDENTITY.
What kind of mess i'll be seeing in the future?
Can't GUID size indexing problem be solved with partitioning?
Can you suggest other alternatives to GUID, based on the above scenario?
Thanks in advance