格納されるエンティティには、25 以上のプロパティ (テーブルの列) があります。エンティティはかなり多様です。つまり、ほとんどの列は空です。平均して、20% 未満 (<5) のプロパティが特定のアイテムに価値を持っていると言えます。そのため、ほとんどのテーブル行に冗長な空の列がたくさんあります。ほぼすべての列が 10 進数です。
このシナリオを考えると、代わりに列をシリアル化することをお勧めしますか、それとも、可能なすべてのプロパティを含む「Property」という名前の別のテーブルを作成してから、外部キーを使用してプロパティをエンティティにマップするさらに別のテーブル「EntityProperty」を作成することをお勧めしますか? ? それともそのままにしておきますか？
この種の冗長性が発生するシナリオの例は次のとおりです。
私たちはたくさんの惑星がある架空の宇宙を持っています。私たちは宇宙採掘ゲームを作成しており、各惑星には 30 種類の鉱物が含まれています。ほとんどの惑星には 2 ～ 3 個の鉱物しかありません。
最も簡単な解決策は、鉱物ごとに 1 つずつ、30 の列を持つ単一のテーブル 'Planets' を作成することです。ここでの問題は、「Planets」テーブルのほとんどの行に 25 以上の列があり、それぞれの値が null またはゼロであることです。したがって、多くの冗長データがあります。たとえば、500k-1M のレコードがあるとします。nullまたはゼロの10進値を保存するには、最大で1バイトかかると思います。したがって、500,000〜1,000,000バイトのスペースを無駄にします。せいぜい1メガバイト。
もう 1 つの解決策は、2 つの追加のテーブルを作成することです。「Planets」テーブルにすべてのミネラルを格納する代わりに、それらをすべて取り出して、「Minerals」と呼ばれるミネラルのテーブルを作成します。これには、異なる鉱物の種類ごとに 1 つずつ、30 行のみが含まれます。次に、惑星の行と鉱物の行への参照を含む「PlanetMineral」というテーブルを作成します。さらに、このテーブルには、惑星が持つ鉱物の量を示す列があります。明らかに、多くのデータベース システムでは、複数の結合を実行する必要があるため、クエリが複雑になります。私はLINQ to SQLでSQLサーバーを使用しています。これは、コードからアクセスできるクラスオブジェクトプロパティに外部キー制約を足場にします。(つまり、planet.Minerals を使用して、惑星が持っているミネラルに簡単にアクセスできます) したがって、この観点からは、そうではありません。複雑さを加える必要はありません。冗長性は、最初のソリューションのごく一部 (1/15 など) です。まだいくらかのオーバーヘッドがある理由は、保存する必要がある外部キーのためです。
データ クエリの効率に関しては、クエリのコストがこれら 2 つのソリューション間でどのように比較されるかはわかりません。