以下の投稿で詳しく説明されているように、シーケンシャル GUID を主キー/UUID として使用することを計画しています。
標準 Guid と比較して Sequential Guid のパフォーマンスの向上は何ですか?
Web ファーム環境で複数の Web サーバーにまたがってこれらの GUID を生成する限り、問題があるかどうか疑問に思っています。衝突の可能性は信じられないほど低いと思いますが、これらの GUID の生成に Web サーバー/タイムスタンプの MAC アドレスが関与していることは間違いないという事実は、私を一時停止させます。トラフィックの多い Web サイトでは、順序が乱れて、順次 GUID を使用する利点が失われる可能性があるのではないかと思います。
あなたの経験が何であるか教えてください。
価値があるのは、私の環境はASP.NET 3.5、Oracle 11gを使用するIIS 7です。ちなみに、Oracle で GUID に使用するデータ型は何ですか? Sql Serverには「一意の識別子」があることを知っています
アドバイスありがとうございます -Venu
私はあなたが言及している投稿の作成者だったので、私はそれに答えることができます。
2〜8台のアプリケーションサーバーを備えたWebファームで、投稿に示されているC＃コードを使用しており（返信の1つに詳細な順序を変更せずに、パフォーマンスをもう少し向上させることができると思います）、同時実行の問題は発生しませんでした、WindowsコアDLLに実装されているSequentialGuid関数は、さまざまなマシンでさまざまなGUIDを作成する処理をすでに行っていると思います。
異なるマシンが異なるGUIDを挿入するデータベース操作では、Webファーム内の異なるアプリケーションサーバーがデータベースの特定の領域に存在するデータを書き込むことを意味します（つまり、アプリケーションサーバーは12345で始まるGUIDを書き込み、もう1つは12345で始まるGUIDを書き込みます62373）したがって、ページ分割があまり頻繁に発生しない（または発生しない）ため、インデックスの更新は引き続き効率的に機能します。
したがって、私の経験から、元のメッセージで概説したのと同じ戦略を使用してGuidを生成しても、適切な方法を使用してGuidを生成する場合は、Webファームの環境で作業している場合でも、特定の問題は発生しません。
コードからGuidを作成したり、中央でGuidを作成したりすることは絶対に避けたいと思います。
データ型に関しては、多くのスペースを浪費するのが好きなので、char（36）を使用しました。冗談はさておき、明確な形式のデータを使用するとメンテナンスが大幅に容易になるため、長くて冗長な方法でデータを書き込むことにしましたが、Oracle GUIDまたは単にRAW（16）データ型を使用できます（基本的に同じです）。各行に20バイトのスペアを用意します。データの参照と編集を簡単にするために、GUIDのテキスト表現が表示されるように、生のGUIDデータをコーディングおよびデコードするためのいくつかの機能を顧客に提供できます。
オラクルのガイド
NHibernate の Guid Comb ジェネレーターがどのように機能するかを確認することをお勧めします。衝突は聞いたことがありません。
一意の GUID を持つようにするために、1 つのサーバーのみがその GUID の作成者になることができます。
メモリが機能する場合、Oracle は MS の「GUID for OLE」の作成をサポートしていませんが、これを利用して非常に類似したものを生成できるはずです: RAWTOHEX(SYS_GUID())
または、GUID の生成のみを担当する単一のサーバーに別のアプリケーションを配置することもできます (たとえば、GUID を生成して返すことだけを目的として、特定のサーバーにある Web サービスを呼び出します。
最後に、GUID はシーケンシャルではありません。次々と生成したとしても、整数とまったく同じようにはインクリメントされません (つまり、最後の桁が CD から 1 ステップで移動するわけではありません)。順序付けには、整数またはその他の数値データ型が必要です。