如何将字符串键映射到唯一的整数 ID?

发布于 2024-08-28 21:06:02 字数 840 浏览 14 评论 0原文

我有一些数据定期从数据源转储,其中的字符串自然键很长(最多 60 个字符)并且与最终用户无关。我在 url 中使用此键。这使得网址太长并且用户不友好。

我想将字符串键转换为整数,并满足以下要求:

源数据集将随着时间的推移而变化。

ID 应该是:

  • 非负整数
  • 唯一且恒定 即使输入键集发生变化
  • 最好可逆回键(不是强要求)

每次都从头开始重建数据库,所以我记不起已经分配的 ID 并匹配将新数据设置为现有 ID,并为添加的键生成顺序 ID。

目前大约有 30000 个不同的键,并且该组还在不断增加。

如何实现将字符串键映射到整数 ID 的函数?

我想到的是:

1. 内置 string.GetHashCode:

ID(key) = Math.Abs​​(key.GetHashCode())

  • 不保证是唯一的
  • (不可逆)

1.1 “重新散列”内置 GetHashCode,直到生成唯一 ID 以防止冲突。

  • 如果将某些冲突添加到输入数据集的开头,现有的 ID 可能会发生变化

2. 一个完美的哈希函数

  • 我不确定如果输入集发生变化
  • (不可逆)

,这是否可以生成恒定的 ID 3. 转换为基数 36/64/??

  • 长度不够短的按键还有

什么其他选择?

I have some data that comes regularily as a dump from a data souce with a string natural key that is long (up to 60 characters) and not relevant to the end user. I am using this key in a url. This makes urls too long and user unfriendly.

I would like to transform the string keys into integers with the following requirements:

The source dataset will change over time.

The ID should be:

  • non negative integer
  • unique and constant even if the set of input keys changes
  • preferrably reversible back to key (not a strong requirement)

The database is rebuilt from scratch every time so I can not remember the already assigned IDs and match the new data set to existing IDs and generate sequential IDs for the added keys.

There are currently around 30000 distinct keys and the set is constantly growing.

How to implement a function that will map string keys to integer IDs?

What I have thought about:

1. Built-in string.GetHashCode:

ID(key) = Math.Abs(key.GetHashCode())

  • is not guaranteed to be unique
  • (not reversible)

1.1 "Re-hashing" the built-in GetHashCode until a unique ID is generated to prevent collisions.

  • existing IDs may change if something colliding is added to the beginning of the input data set

2. a perfect hashing function

  • I am not sure if this can generate constant IDs if the set of inputs changes
  • (not reversible)

3. translate to base 36/64/??

  • does not shorten the long keys enough

What are the other options?

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

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

发布评论

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

评论(3

听你说爱我 2024-09-04 21:06:02

仅当您可以保留分配的 ID 列表时才能执行此操作。

对于任何实际为当前集合提供唯一 ID 的给定算法,任何新值都不能保证获得唯一 ID。

字符串包含大约 400 位信息,因此要获得保证唯一的整数,它必须包含字符串中的所有信息并且大约为 400 位。这是用十进制数表示的 120 个字符,因此不会比您现在的长度短。

You can only do that if you can keep a list of assigned IDs.

For any give algorithm that actually gives you unique ID for the current set, any new value is not guaranteed to get a unique ID.

The strings contain about 400 bits of information, so to get an integer that is guaranteed to be unique it would have to contain all the information from the string and be about 400 bits. That's a 120 characters expressed as a decimal number so that's not shorter than what you have now.

尘曦 2024-09-04 21:06:02

Base64 编码的 sha1sum 是 27 个字符。 base64(md5(...)) 是 22 个字符。如果更小,您将面临不可忽视的碰撞风险。

当输入集发生变化时,完美的散列函数是不可能的。

A Base64-encoded sha1sum is 27 characters. base64(md5(...)) is 22 characters. Any smaller and you will have a non-negligible risk of collisions.

Perfect hashing functions aren't possible when the set of inputs changes.

逆蝶 2024-09-04 21:06:02

设置第二个持久数据库并将您的 KEY/ID 对存储在那里。确保表中还有数据的日期,以便您可以进行一些整理工作。

Set up a second, persistant DB and store your KEY/ID pairs there. Make sure you also have the data's date in the table so you can do some house-keeping.

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