3
プライマリキーがuniqueidentifierであり、クラスタ化インデックスがbigintのID列であるテーブルスキーマがあります。主キーからクラスタ化インデックスを分離するEntity Framework
Guidインデックスが断片化する可能性があり、断片化される場合は、実際には挿入が遅くなるため、クラスタ化インデックスではないことをお勧めします。つまり、行を可能な限り順番に挿入します。
しかし、私はクラスタ化されたインデックスをEFの概念レイヤに伝播させたくありません。クラスタード・インデックスは単にそのようなレコードの物理的な場所であり、プログラマーはそれについて何も知る必要はありません。彼らが懸念している限り、彼らはGuid PKを扱っているだけです。そこでモデルからプロパティを削除しました。
しかし、クラスター化されたインデックス列はNULL値ではなく、既定値を持たず、どちらもID列であり、既定値を持つこともNULL可能でもないという意味で無意味です。
プロジェクトをコンパイルするにはどうすればよいですか？
注：私はGuidとSequential GuidとInt Idについて議論したくありません。このシステムはスケールアウトが可能でなければならず、それは私が関心を寄せるGuid PKを意味します。
bigint列を何も使用していない場合は、これがどのように役立つのですか？ – scottm
彼はクラスタ化されたインデックスとしてこれを使用しています（データベースのパフォーマンスを向上させるため）。 –
@ypercubeこれは意味がありません。その列に対してクエリを実行していない場合は、そのインデックスを使用していません。 OPがGUID列に対してのみクエリを実行する場合、これはクラスタ化されたインデックスと同じである可能性があります。実際にはより多くの順序付けられたインデックスが必要な場合は、順次GUIDを使用する必要があります。 2番目のインデックスを追加することで、行を挿入するのにかかる時間が増え、OPが示唆していることを実行することで、（わずかに）レコードを照会するのにかかる時間が増加します。 – scottm