これらのテーブルの変更を追跡するために、DB rowversion のほとんどのテーブルに追加する予定です。追加するとクエリのパフォーマンスに影響することはわかっています。
それがパフォーマンスに少し影響するか (数パーセント遅くなるか)、DB の速度が大幅に低下するため、多くのテーブルに rowversion を追加するべきではないかどうかは誰にもわかりません。
これらのテーブルの変更を追跡するために、DB rowversion のほとんどのテーブルに追加する予定です。追加するとクエリのパフォーマンスに影響することはわかっています。
それがパフォーマンスに少し影響するか (数パーセント遅くなるか)、DB の速度が大幅に低下するため、多くのテーブルに rowversion を追加するべきではないかどうかは誰にもわかりません。
rowversion / timestamp列を追加するだけのパフォーマンスの違いは、行が8バイト広くなることです。
実際のパフォーマンスの違いは、実際に何かに使用し始めたときに発生します。しかし、同様の質問に対する私の答えで指摘しているように、RowVersionとパフォーマンス
rowVersion
更新されたアイテムをチェックするためにフィールドを使用せず、代わりに、最後に読んだ後でレコードが更新されないようにするために一貫性を保つためにフィールドを使用する場合、これは完全に許容できる使用法であり、影響はありません。そのような:
UPDATE MyTable SET MyField = ' @myField
WHERE Key = @key AND rowVersion = @rowVersion
したがって、行をチェックして、アプリケーションが最後に読み取った後に更新されていないことを確認するときのパフォーマンスは、わずかなパフォーマンスの違いになります(とにかく更新するには行を読み取る必要があります)。
ただし、前回チェックしてから更新されたすべてのアイテムを取得する手段としてrowversion / timestamp列を使用しようとすると、パフォーマンスが非常に低下します。