I need to decide on a primary key for my tables in a merge replication scenario (currently one laptop taken into the field during the day while another user works on a desktop; both users need read-write access to the same data).
I've read several articles discussing GUIDs vs. Identity columns vs. sequential GUIDs, etc. None of these articles specifically addresses merge replication.
I'm trying to identify potential downstream pitfalls among the following three options:
- (A) GUID Primary/Clustering key with default of NewSequentialID()
- SQL Server will be adding a GUID field anyway for merge replication...
- ...but making it the Clustering key will add it at the leaf of every index (as I understand it)
- 16 bytes
- NewSequentialID() is not sequential over reboots (does this really matter?)
- (B) Composite key of Identity column ID + ServerID
- Only 5 bytes total (ID int, ServerID tinyint)
- Requires a lookup table or other scheme to get ServerID
- (C) AutoNumber Identity PK implemented via Automatic Identity Range Management
- this is a nightmare I'd like to avoid unless someone offers a compelling argument in its favor
A few final notes:
- These tables will be linked to from 32-bit MS Access, which does not have ideal support for bigint, so that is not a practical option
- The total number of subscribers that will require unique ServerIDs should not exceed 3 and will never approach 255
- The database itself will be very small (under 1 million records across all tables over its lifetime)