複雑なシステムでは、複数のエンティティに関連する一般的なサブシステムを持つことは非常に一般的ですか。例として、要求、ジョブ、および評価がそれぞれ独自のワークフローを持つワークフロー エンジンが考えられます。
ユーザーが個人情報フォームや従業員履歴フォームを持っている可能性のあるフォーム エンジンなどのサブシステムへのリンクが 1 つ以上ある場合もあります。
エンティティが複数のログ レコードを持つことができる場合、ロギングをサブシステムと見なすこともできます。
この「コンテキスト」をモデル化する方法はいくつかあります。1 つは KVP スタイルを使用する方法です。
CREATE TABLE ワークフロー (WorkflowID、ContextObject varchar(20)、ContextKey int )。ここで、ContextObject には「Job」、「User」、「Assessment」のいずれかが含まれ、ContextKey は JobID、UserID、AssessmentID などのいずれかになります。
もう 1 つの方法は、null 許容列を持つ幅の広いテーブルを使用することです。
CREATE TABLE ワークフロー (WorkflowID、JobID INT NULL、UserID INT NULL、AssessmentID INT NULL )
コンテキスト キーが相互に排他的である場合。
特に行数が数十万から数百万に増加するにつれて、パフォーマンスの観点からどのアプローチが「より良い」のか疑問に思っていますか?
KVP スタイルのテーブルはより狭い行 (より大きなテーブル) になり、null 許容列のアプローチではより広い行になりますが、これらの行に対して個々のインデックスを構築できます。SQL Server を使用すると、フィルター処理されたインデックスを使用して、contextID が null でない各コンテキストのインデックスを作成できます。
nullable-column アプローチを使用すると、オプティマイザが利用できる統計が向上します。つまり、JobID に基づく結合の場合、オプティマイザは、そのテーブルの 100 万行のうち、10,000 行だけが jobID に関連していることを認識します。
この 2 つの異なるアプローチについて、人々はどのような考えを持っているのだろうかと思います。
各コンテキストがかなり高いカーディナリティ (コンテキスト タイプごとにほぼ 1) を提供すると仮定します。また、SQL Server の最近のバージョンを想定します。