衝突のリスクはわずかに高くなりますが、それでもほとんどありません。次のことを考慮してください：
-
Combと
NEWIDの両方 /NEWSEQUENTIALID数ミリ秒までの精度でタイムスタンプを含めます。したがって、まったく同じ瞬間に多数のIDを生成している場合を除きます。 これらのさまざまなソースのすべてから、文字通り不可能 IDが衝突する場合。 -
GUIDのではない部分 タイムスタンプに基づくと、ランダムと考えることができます。ほとんどのGUIDアルゴリズムは、これらの数字をPRNGに基づいています。したがって、これらの他の10バイト程度の衝突の可能性は、2つの別個の乱数ジェネレーターを使用して衝突を監視した場合と同じオーダーです。
これについて少し考えてみてください。PRNGは繰り返し番号を実行できるため、わずかに異なるアルゴリズムを使用している場合でも、2つの間の衝突の可能性は1つだけを使用した衝突よりも大幅に高くはありません。これは、毎週同じ宝くじの番号をプレイするのと、毎週ランダムなセットを選ぶのと同じようなものです。どちらの方法でも、当選の確率はまったく同じです。
ここで、Guid.Combのようなアルゴリズムを使用する場合、一意化子は10ビットしかないことに注意してください。これは、1024個の個別の値に相当します。したがって、同じ数ミリ秒以内に膨大な数のGUIDを生成する場合は、 衝突する。ただし、かなり低い頻度でGUIDを生成する場合、同時に使用するさまざまなアルゴリズムの数は実際には問題ではなく、衝突の可能性は実際には存在しません。
絶対に確信できる最善の方法は、テストを実行することです。 2つまたは3つすべて（または使用する数）のGUIDを同時に定期的に生成し、それらをログファイルに書き出して、衝突が発生するかどうか（発生する場合はその数）を確認します。これにより、これが実際にどれほど安全であるかがわかります。
P.S. NHibernateのコームジェネレーターを使用してクラスター化された主キーのGUIDを生成している場合は、NEWSEQUENTIALID()の使用を検討してください。 NEWID()の代わりに --Combの要点はページ分割を回避することであり、非順次アルゴリズムを使用する他のプロセスがある場合、それを達成することはできません。また、Guid.NewGuidを使用してコードを変更する必要があります 同じCombジェネレーターを使用する-NHibernateで使用される実際のCombアルゴリズムは複雑ではなく、独自のドメインロジックで簡単に複製できます。
†NEWIDについては論争があるようです。 、およびタイムスタンプが含まれているかどうか。いずれの場合も、MACアドレスに基づいているため、可能な値の範囲はV4GUIDまたはCombよりもかなり小さくなります。データベース外のCombGUIDとNEWSEQUENTIALIDに固執することをお勧めするもう1つの理由 データベース内。