nHibernate でテーブルの主キーに整数 ID の代わりに GUID を使用すると、どのようなオーバーヘッドが発生しますか?
使用の主な理由は、ユーザー向けデータのテーブル ID の難読化です。
nHibernate でテーブルの主キーに整数 ID の代わりに GUID を使用すると、どのようなオーバーヘッドが発生しますか?
使用の主な理由は、ユーザー向けデータのテーブル ID の難読化です。
GetById、フィルター処理された最初の 50 レコードの検索、削除、更新などの操作の日常レベルへの影響はゼロです。測定可能な違いはまったくありません。
大きく影響を受けるのは、データベースストレージです。整数は 4 バイトで格納され、Guid は 16 を消費します。したがって、100 万行ごとに 12 MB の追加のストレージが必要になります。そのようなエンティティが他のエンティティを参照する場合、参照されるテーブルごとにさらに 12 MB が必要です。そして、そのような列がインデックスに使用されると...スペースがますます大きくなる可能性があります。
そのため、大規模な場合、SQL サーバーはより大きなデータをスキャンする必要があります。たとえば、MS SQL Server は int 型に最適化されています。(bigint、shortint、tinyint を含む)。
しかし、正直なところ、私たちは両方のアプローチを使用しており、パフォーマンスの問題は常に別の場所にありました...
可能であれば、毎回intに基づいて主キーに投票します 。
後で MVC ルーティングを controller\action\id から別のものに変更しますが、id は int のままにします。プロパティとして GUID を導入し (スペースを消費するが、参照テーブルではなくスペースのみを消費する)、ルーティングをcontroller\actin\uniqueGuidに変更し、ビジネス レイヤーでユーザーを難読化する必要がある場合は GetByGuid を呼び出すことができます。