I have spent the best part of a day researching and testing different methods of syncing a SQL server database with CoreData on the Mac. I have tested both INT’s and GUID’s (sequential GUID’s also) as my primary keys and although GUID’s are by far the worst in terms of performance I can’t see no other way of ensuring uniqueness across systems.
Is using GUID’s for primary keys the wrong way to go when syncing data between platforms? I find it hard to believe that companies use GUID’s when syncing, but most articles I read on the subject seem to point to just that. If developers are using GUID’s does anybody know how performance can be improved? I tried using a GUID as a primary key with a non clustered index and created a date field as my clustered index with no great performance improvement.
Any help would be much appreciated, especially if you have tackled a similar problem.
GUIDs make syncing a lot easier. Sequential guids will alleviate the fragmentation issue strongly, leaving only the 16 byte column size as the major issue.
As long as you ensure you have another sequential and narrow column as your clustered key, you’ll save a lot of space for your nonclustered indexes – it seems like you already know this.
Assuming you’re not dealing with GBs of data, performance shouldn’t be that affected by a GUID in this case, given you’ve already handled the GUID column with proper care.
If you only need to sync two systems, I’ve previously created systems where A would use an identity(-1,-1) as the primary key where the other system used an identity(1,1) as the primary key. That ensure easy syncing while keeping the primary key nice and narrow. Won’t work for more than two systems however.