与えられた一意の文字列に対して一意のレコードIDを生成する必要があります。cutdown uuidさらに短い文字列を作成する
私は良いと思われるuuid形式を使ってみました。
しかし、私たちはそれが長いと感じています。
ですから、uuid文字列9f218a38-12cd-5942-b877-80adc0589315を小さくする必要があります。 ' - 'を削除することで、4文字を節約できます。 uuidから削除する最も安全な部分は何ですか？普遍的な一意のIDは必要ありませんが、uuidをソースとして使用したいが、文字列を減らすことができます。
サイト/データベース（SQL Server/ADO.NETデータサービス）に固有の固有IDが必要です。
任意の言語から任意のアイデアやサンプルは、事前
あなたはおそらくuniqueindentifierデータ型を使用する必要がありますMS-SQLを使用している場合、それは（16バイト）コンパクトでもあるし、SQLエンジンはそれについて知っているので、それを使用して、インデックスとクエリを最適化することができます。
UUIDは128ビットです。あなたはそれのCRCを行うことを考えましたか？それは16ビットまたは32ビットに簡単に落とすことができ、すべての元の情報を使用します。 CRCが十分でない場合は、常に適切なハッシュの最初の数バイト（SHA256など）を使用できます。
実際にUUIDを切り捨てたい場合は、そのフォーマットはRFC 4122で記述されています。あなたは、あなたの実装がそれから必要としない部分を理解することができるはずです。
CRCは一意ではありません。 –
彼が必要とする一意性に依存します。だから私はCRCと代替の両方を提案した。 –
残念ながら、UUIDとしてのステータスを取り除かずに、UUIDの生のビットを減らすことはできません。これは、UUIDとみなされるために128ビットのランダム性が必要であり、衝突の可能性を十分にゼロに近づけるためである。 –
UUIDは（ほぼ）128ビットの一意性を提供します。 16バイナリバイト、または22のbase64エンコード文字に短縮できます。私はUUIDの一部を削除することをお勧めしません。それ以外の場合は、その意味が失われます。 UUIDは、すべての128ビットが意味を持つように設計されています。それよりも少ない場合は、他のスキーマを使用する必要があります。
たとえば、バージョン4のUUIDのみが使用されることが保証されている場合は、最初の32ビット、または最後の32ビットのみを使用できます。あなたは一意性を失いますが、かなり乱数があります。固定ビット（バージョンとバリアント）を避けるだけです。
ただし、保証できない場合は、実際の問題が発生します。バージョン1のUUIDの場合、同じ日に生成されたUUIDの最初のビットは一意ではなく、同じシステムで生成されたUUIDの最後のビットは一意ではありません。 UUIDをCRC化しても、16または32ビットの一意性が保証されるわけではありません。
この場合、他の方式を使用してください。システムの乱数ジェネレータを使用して32ビットの乱数を生成し、これをあなたの一意のIDとして使用します。その長さを取り除くつもりなら、UUIDに頼らないでください。
UUIDは128ビットまたは16バイトです。エンコーディングがないと、16バイトという低い値になる可能性があります。 UUIDは通常16進数で書かれ、32バイトの読み込み可能な文字列になります。他のエンコーディングを使用すると、異なる結果を得る：
これは、読み込み可能な文字列と標準/共通のエンコーディングを使用するかどうかによって異なります。
UUIDも16バイトなので、これではそれほど小さくなりません。 –
Glenn、uniqueindentifier == UUIDですが、OPは間違いなく文字列として格納することを話していました。 –