我正在寻找一种方法,可以为在本地创建的record类生成唯一标识符,然后以各种格式(XML、SQL等)持久化。
我见过人们使用DateTime和GetHashCode,但根据样本大小的不同,这似乎会导致重复的标识符。
GUID有点夸张了,因为我不需要全局级别的任何唯一(大)的东西。我也知道使用GUID和GetHashCode来减少一些大小,但是这里也会突然出现重复的内容。
有没有人能推荐一种生成简单唯一标识符的最佳实践或方法?
发布于 2010-09-01 04:51:21
Guid或递增计数器。
Guid可以“从空中”生成,但会占用更多空间
对于计数器,您需要将计数器存储在某个地方,并且如果您使用线程,则需要使其线程安全。但它的尺寸更小。
发布于 2010-09-01 05:07:26
实现你自己的几乎总是一个错误。较小的唯一数字需要对上次使用的数字进行真正可靠的记录。这是很难做到的,硬盘有磁头崩溃,注册表偶尔会损坏。您需要对其进行组织,以便存在单点故障。类似于dbase的自动递增列。确保如果丢失了最后一个数字,也会完全丢失数据。这意味着,首先,用户不应该在不复制最后一个数字的记录的情况下复制数据。或者您总是拥有所有数据的可靠副本,并且可以从中恢复最后一个数字。快点。
您还将很难确保数字自动递增。仅仅启动程序的两个实例通常就足以造成混乱。解决这个问题很棘手,您需要一个独立的仲裁器进程来存储数字。
然后就是不得不猜测10年或20年后会发生什么的负担。到那时,你的应用程序会扩展到满足需求吗?这是非常罕见的,指望机器变得更快已经结束了。什么是本地唯一的数字现在需要成为全球唯一的数字。对此有非常不同的要求。
别胡闹了,16个字节不算什么。使用Guid。
发布于 2010-09-01 04:54:19
GetHashCode绝对不是一个非常好的选择。
您希望标识符有多大?
如果您有持久存储来记住“最后生成的”标识符(例如数据库),那么每次简单地递增一个数字就足够了。如果您没有持久存储,那么使用DateTime来获取从某个固定日期开始的毫秒数也是可行的。这显然会限制您每毫秒只能生成一个标识符,但根据您的情况,这应该是可以的。
如果您有多个进程同时生成标识符,您可以将时间戳与您的进程ID或其他东西结合起来,以避免重复。
https://stackoverflow.com/questions/3613120
复制相似问题