Best way to create unique identities for distributed data that will be merged?

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开发者_如何学Python 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

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

As you said, GUIDs come to mind for many obvious reasons some of which are covered here Primary Keys: IDs versus GUIDs

You may want to read this answer also What's the best practice for primary keys in tables?