システム内の一部のデータを識別するための一意の ID を生成しようとしています。System.Guid.NewGuid()s を使用して、いくつかの (一意ではない関連性のある) メタデータを連結する精巧なシステムを使用しています。このアプローチには欠点がありますか、それとも私は明確ですか?
3 に答える
システム内の一部のデータを識別するための一意の ID を生成しようとしています。
GUID は定義上、グローバルに一意の識別子であるため、GUID をお勧めします。
System.Guid.NewGuid() を使用して、いくつかの (一意ではない関連性のある) メタデータを連結する精巧なシステムを使用しています。このアプローチには欠点がありますか、それとも私は明確ですか?
まあ、あなたが欠点と考えるものがわからないので、言うのは難しいです. いくつかの考えられる欠点が思い浮かびます。
GUID は大きい: 128 ビットは大量のビットです。
GUID が特定の分布を持つことは保証されていません。GUID を順番に生成することは完全に合法であり、124 ビット空間 (もちろん、128 ビットからバージョン番号である 4 ビットを差し引いたもの) に均一に分散することも完全に合法です。これは、データベースに深刻な影響を与える可能性があります。 GUID によってソートされた順序でインデックスが作成されたデータベースで、GUID が主キーとして使用されている場合のパフォーマンス。新しい行が常に最後にある場合、挿入ははるかに効率的です。均一に配布された GUID が最後になることはほとんどありません。
バージョン 4 の GUID は、暗号的にランダムである必要はありません。GUID が非暗号ランダム ジェネレーターによって生成された場合、攻撃者は理論上、代表的なサンプルが与えられたときに GUID が何であるかを予測できます。理論上、攻撃者は同じセッションで 2 つの GUID が生成された可能性を判断できます。もちろん、バージョン 1 の GUID はほとんどランダムではなく、洗練された読者にはいつどこで生成されたかがわかります。
等々。
数週間以内に、GUID のこれらの特性やその他の特性に関する一連の記事を計画しています。詳細については、私のブログをご覧ください。
を使用System.Guid.NewGuid()
する場合でも、GUID がシステムにまだ存在していないことを確認する必要がある場合があります。
GUID は非常に複雑で事実上一意ですが、確率を除いて、GUID がまだ存在しないことを保証するものは何もありません。ほとんどの場合、それはユニークであることと同じであるという点で、統計的に信じられないほどありそうにありません.
同一の GUID を生成することは、宝くじに 2 回当選するようなものです。実際にそれを妨げるものは何もありません。
ほとんどの場合、既存の一致をチェックしなくても済む可能性がありますが、大量の生成が行われている非常に極端な場合、またはシステムが絶対に失敗してはならない場合は、チェックする価値があります。
編集
もう少し明確にさせてください。重複した GUID が表示される可能性は非常に低いです。それがポイントです。それは「グローバルにユニーク」です。つまり、重複する可能性が非常に小さいため、ユニークであると想定できます。ただし、航空機を空に維持したり、原子炉を監視したり、国際宇宙ステーションでの生命維持を処理したりするコードについて話している場合、個人的には重複をチェックします。そのエッジケースをヒットします。一方、ブログ エンジンを作成しているだけの場合は、チェックせずにそのまま使用してください。
ご自由にお使いNewGuid()
ください。その独自性に問題はありません。
同じ GUID を 2 回生成する可能性が低すぎます。良い例をここで見つけることができます: GUID が一意ではないという単純な証明
var bigHeapOGuids = new Dictionary<Guid, Guid>();
try
{
do
{
Guid guid = Guid.NewGuid();
bigHeapOGuids.Add(guid ,guid );
} while (true);
}
catch (OutOfMemoryException)
{
}
ある時点で、重複したキーの競合OutOfMemory
ではなくクラッシュしました。