views:

46

answers:

2

I have a centrally hosted database (MS SQL Server) and distributed clients save data to it over the Internet. When the Internet connection goes down the client starts storing new data locally into a SQLite instance. When the Internet connection comes back online the accumulated local data is moved to the central db (inserted).

What's the best way to handle unique IDs in this scenario? Other important info:

  • Local clients can remember their local db IDs for linking purposes while offline; therefore local ids must be generated as globally unique.

  • a unique ID in a local db should not be changed when merged back into the central db.

  • Different kinds of databases might be chosen for local operations in the future depending on the device - e.g. a JavaDb, a TextFileDb etc; therefore I think no single proprietary db feature should be used for this solution.

  • When changes are merged back to the central db all records must have unique IDs.

For this question assume a simple table named MyTable with fields: ID (the primary/unique key whatever type that should be) and Field1, Field2, Field3 The latter don't really matter.

What first came to mind is using GUID. Is there a pattern or practice that's better than this or a better way to carry this out?

Edit: Using Microsoft .NET and ADO.NET

A: 

As you said, GUIDs come to mind for many obvious reasons some of which are covered here http://www.codinghorror.com/blog/archives/000817.html

You may want to read this answer also http://stackoverflow.com/questions/337503/whats-the-best-practice-for-primary-keys-in-tables

AlexanderN
+1  A: 

The GUID works.

Beyond that, this is largely a solved problem with the Microsoft Sync Framework (you didn't mention your development platform, so there is an assumption here). It is not tied to any db or datatype or protocol, and can be configured to work in a variety of offline scenarios (okay, this is starting to sound like a commercial...)

http://msdn.microsoft.com/en-us/sync/bb887625.aspx

Jay
Your assumption is correct. I added the tags [ado.net] and [.net]
John K
Sync Framework is the direction I will take. Thank you for proposing it; I had not heard of this technology before. To get a high level overview of Sync, this .NET Rocks radio show was useful for me: http://www.dotnetrocks.com/default.aspx?showNum=499
John K