0

長い（最大60文字）文字列の自然キーを使用してデータソースからダンプとして定期的に送信されるデータがあり、エンドユーザーには関係ありません。このキーをURLで使用しています。これにより、URLが長すぎて、ユーザーにとって使い勝手が悪くなります。

次の要件で文字列キーを整数に変換したいと思います。

ソースデータセットは時間の経過とともに変化します。

IDは次のようになります。

  • 非負の整数
  • 入力キーのセットが変更されても一意で一定
  • できればキーに戻すことができます（強い要件ではありません）

データベースは毎回ゼロから再構築されるため、すでに割り当てられているIDを思い出せず、新しいデータセットを既存のIDと照合して、追加されたキーのシーケンシャルIDを生成できません。

現在、約30000の異なるキーがあり、セットは絶えず成長しています。

文字列キーを整数IDにマップする関数を実装するにはどうすればよいですか？

私が考えたこと：

1.組み込みのstring.GetHashCode：

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

  • 一意であるとは限りません
  • （リバーシブルではありません）

1.1衝突を防ぐために一意のIDが生成されるまで、組み込みのGetHashCodeを「再ハッシュ」します。

  • 入力データセットの先頭に衝突するものが追加されると、既存のIDが変更される可能性があります

2.完璧なハッシュ関数

  • 入力のセットが変更された場合にこれが定数IDを生成できるかどうかはわかりません
  • （リバーシブルではありません）

3.ベース36/64/に変換しますか？

  • 長いキーを十分に短くしません

他のオプションは何ですか？

4

3 に答える 3

1

Base64でエンコードされたsha1sumは27文字です。base64（md5（...））は22文字です。これより小さくすると、衝突のリスクが無視できないほどになります。

入力のセットが変更されると、完全なハッシュ関数は不可能になります。

于 2010-04-17T07:15:41.050 に答える
1

割り当てられたIDのリストを保持できる場合にのみ、これを行うことができます。

現在のセットに実際に一意のIDを与えるgiveアルゴリズムの場合、新しい値が一意のIDを取得することは保証されません。

文字列には約400ビットの情報が含まれているため、一意であることが保証されている整数を取得するには、文字列からのすべての情報が含まれ、約400ビットである必要があります。これは10進数で表される120文字なので、現在の文字よりも短くはなりません。

于 2010-04-17T07:39:39.277 に答える
0

2番目の永続的なDBをセットアップし、そこにKEY/IDペアを保存します。いくつかのハウスキーピングを実行できるように、テーブルにデータの日付もあることを確認してください。

于 2010-04-17T07:17:57.800 に答える