Question

I’m building a desktop application that will run on multiple laptops. It will need to sync up to a central database whenever the user is back in the office and has access again.

My biggest problem to overcome is how to design the database so that it is easily synced with the central database server. One of the major hurdles is trying to determine how to handle keys such that they don’t duplicate across the multiple laptop databases that’ll be in use.

For example, say Laptop 1 enters a new customer called “Customer A” – using a unique id, it might be assigned a customer ID of 20. Laptop 2 enters “Customer C” – it could also assign the ID of 20 to that customer. When it comes time to sync, both customer A & C would end up on the server with a duplicate ID.

Has anyone worked with an app similar to this that has an elegant solution?

Answer 1

Alternatives are:

• ranges of ids, which are difficult to implement and to enforce. They are very hard to manage, is difficult to provision an new site/range and is even more difficult to cope with retired sites/ranges.
• composite keys, (siteId, EntityId) are better than ranges but require upfront design and may cause problems on queries that aggregate multiple/all sites (central DWs) because the leftmost key in all indexes (siteId) is not specified.
• GUIDs. In theory they are perfect as they guarantee uniqueness (they may conflict in theory, I’m yet to see a true guid conflict). In practice they are very poor clustered key choices because of the size (16 bytes) and because of the fragmentation. Still, they are much easier to get right than the composite key approach.