为将要合并的分布式数据创建唯一身份的最佳方法?

发布于 2024-08-19 15:35:31 字数 763 浏览 4 评论 0原文

我有一个集中托管的数据库(MS SQL Server),分布式客户端通过 Internet 将数据保存到其中。当互联网连接中断时,客户端开始将新数据本地存储到 SQLite 实例中。当互联网连接恢复在线时,累积的本地数据将移动到中央数据库(插入)。

在这种情况下处理唯一 ID 的最佳方法是什么?其他重要信息:

  • 本地客户端可以记住其本地数据库 ID,以便在离线时进行链接;因此,本地 ID 必须生成为全局唯一的。

  • 合并回中央数据库时,不应更改本地数据库中的唯一 ID。

  • 根据设备的不同,将来可能会选择不同类型的数据库进行本地操作 - 例如 JavaDb、TextFileDb 等;因此我认为这个解决方案不应该使用任何单一的专有数据库功能。

  • 当更改合并回中央数据库时,所有记录都必须具有唯一的 ID。

对于此问题,假设有一个名为 MyTable 的简单表,其中包含以下字段:ID(主键/唯一键,无论应该是什么类型)和 Field1,< code>Field2, Field3 后者并不重要。

首先想到的是使用 GUID。是否有比这更好的模式或实践,或者更好的方法来执行此操作?

编辑: 使用 Microsoft .NET 和 ADO.NET

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

酷炫老祖宗 2024-08-26 15:35:31

GUID 有效。

除此之外,这很大程度上是 Microsoft Sync Framework 解决的问题(您没有提到您的开发平台,因此这里有一个假设)。它不依赖于任何数据库、数据类型或协议,并且可以配置为在各种离线场景中工作(好吧,这开始听起来像商业广告......

) microsoft.com/en-us/sync/bb887625.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/sync/bb887625.aspx

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

温柔嚣张 2024-08-26 15:35:31

正如您所说,GUID 出于许多明显的原因而浮现在脑海中,其中一些原因已在此处介绍
主键:ID 与 GUID

您可能想阅读此答案还
表中主键的最佳实践是什么?

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?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文