データ型 int の主キーのみを使用してデータベース テーブルを作成しており、常に優れたパフォーマンスを発揮してきましたが、更新可能なサブスクライバーを使用してマージ レプリケーションをセットアップする必要があります。
これらのテーブルでは、一般的な主キー、データ型 int、ID 増分を使用しています。マージ レプリケーションを設定するには、デフォルト値の newsequentialid() 関数を使用してすべてのテーブルに rowguid を追加する必要があります。rowguid がインデックス可能になっていることに気付き、もう主キーが必要かどうか疑問に思っていましたか?
主キー int と rowguid の 2 つのインデックスを使用しても問題ありませんか? マージ レプリケーション テーブルの最適なレイアウトは何ですか? 簡単に行を参照できるように int id を保持し、インデックスを削除して主キーを保持するだけですか? どのルートを取るべきかわからない、ありがとう。
int id列を削除してGUIDに置き換えると、大量のデータとクエリをやり直す必要がある場合があることに注意してください。そして、あなたは本当に次のようなクエリを実行したいですか？
select * from orders where customer_id = '2053995D-4EFE-41C0-8A04-00009890024A'
IDがユーザーに公開されている場合（名前が一意でないために顧客テーブルに自然キーがないことが多いため、多くの場合、顧客の場合）、ユーザーは調査を行うのに気が遠くなるでしょう。
両方を備えている既存のシステムには何の問題もありません。新しいシステムでは、intを使用しないように計画することもできますが、すでに使用しているシステムでintを削除しようとすると、バグが発生するリスクが高くなります。
整数の主キーを GUID (私が知っている) に置き換えることの唯一の欠点は、GUID が大きいため、btree (使用されるインデックス領域) が大きくなり、このテーブルへの外部キーがある場合 (これも変更する必要があります) より多くの領域が (潜在的に) 多くのテーブルで使用される可能性があります。