現在、ユーザーIDにGUIDを使用するASP.NETのSQLメンバーシッププロバイダを使用しています。私のアプリケーションには、Userテーブルへの外部キー関係を持つカスタムテーブルがいくつかあります。標準プロバイダがユーザIDにGUIDを使用したことによるディスクスペースとパフォーマンスの影響が懸念されます。ASP.NETメンバーシッププロバイダ、ユーザーID GUID、およびディスク容量
これに関連して誰かが宇宙/パフォーマンスの問題に遭遇したことがありますか？もしそうなら、人々がこれに対処するために実装したカスタムアプローチがありますか？
ほとんどの洞察力や提案は高く評価されます。
おかげ
たとえば、INTタイプではなくGUIDを使用した結果、スペースに問題が生じるのではないかと疑いがあります。私が警告することの1つは、データベースのGUID列にクラスタード・インデックスを作成したくなることです。こんなことしないで。既定では、GUIDはランダムであり、ランダムなデータをクラスタ化インデックスを持つ列に挿入すると、いくつかの問題が発生します。あなたが知っているように、クラスター化されているとは、物理記憶配列内を意味します。したがって、新しい乱数（GUID）を挿入すると、その行は通常、テーブルの中央に挿入される必要があります。これにより、大量に断片化された索引が作成される可能性があります。
私のアドバイスは、GUIDをINT値（多くのユーザーがいると思われる場合はBIGINT）にリンクし、INTを他の場所で使用するテーブルを作成することです。 Ferminがちょうど言ったように。
は、あなたは、カスタムテーブルに整数を使用することができます整数値にGUIDをマップするカスタム・テーブルを持っていませんでしたか？
SQL Server 2005を使用している場合は、NewSequentialId()メソッドを調べることができます。 Eric Swannは、メンバーシッププロバイダーとの使用についてgood overviewを提供しています。また、デフォルトのランダムなものよりもシーケンシャルなGUIDを使用する利点については、nice articleもあります。ここでは、記事から抜粋したパフォーマンスの比較を示します。
[Reads] [Writes] [Leaf Pages] [Avg Page Used] [Avg Fragmentation] [Record Count]
IDENTITY(,) 0 1,683 1,667 98.9% 0.7% 50,000
NEWID() 0 5,386 2,486 69.3% 99.2% 50,000
NEWSEQUENTIALID() 0 1,746 1,725 99.9% 1.0% 50,000