0

を使用してsql-server-2008-R2います。3 種類のデータを含むテーブルがあり、それらの型は別のテーブルにあります。

T = テーブル、F = フィールド、FK = 外部キー、PK = 主キー

T1: F1(PK), F2(TypeID), F3, F4, F5, F6, F7

T2: F1(TypeID, PK), F2(TypeName)

4 番目のタイプを追加したいのですが、このタイプには追加のプロパティ (TypeRate など) があります。
私の T1 テーブルには、プロジェクト開始の最初の週に少なくとも 300 万のレコードがあり、その後、1 か月あたり約 300 万のレコードにまで遅くなります。

ここで、以下にリストされている方法の中でどの方法が最適かを知りたいです。

A. メイン テーブル (T1) にフィールドを追加します。 

T1: F1(PK), F2(TypeID), F3, F4, F5, F6, F7, F8(TypeRate)

F8 はほとんどの場合 (他のタイプのレコードの場合) null になりますが、テーブルは 1 つだけです。

B. T1 が持つすべてのフィールド (T3) を含む別のテーブルをまったく追加します。

T3: F1(PK), F2(TypeID), F3, F4, F5, F6, F7, F8

ほとんどの場合、T1 が null 値を持たないようにしますが、ほぼ同じ 2 つのテーブルを作成します。

C. 説明テーブルを追加します (T4) :

T4: F1(PK), F2(FK:T1.PK), F3(TypeRate)

T1テーブルにnull値がないように、4番目のタイプのレコードの場合、追加データはT4（説明テーブル）にあります

4

2 に答える 2

1

達成しようとしていることを説明せずに「最良の」解決策を求めることはできません。ええと、あなたは尋ねることができると思いますが、それは質問に答えることを不可能にします。

スペース（メモリとディスクスペース）を最小化しようとしている場合は、オプション（b）で示されているように、テーブルを2つに分割することが最小スペースソリューションになります。ただし、このオプションを選択する可能性はほとんどありません。スペース効率の向上は最小限であり、エンティティを2つのテーブルに分割することは一般的に最善の解決策ではありません。

最初の解決策では、NULLごとに1行あたり約少しオーバーヘッドが発生します。これはごくわずかなスペースです。多くの場合、これは良い解決策のようです。データは、追加の結合なしで利用できます。

3番目の解決策も問題ありません。データをフェッチするには、追加の結合が必要です。ただし、参照テーブルが小さい場合、またはキーにインデックスを作成する場合は、パフォーマンスのオーバーヘッドは無視できるはずです。

私が（d）と呼ぶ別の解決策があります。つまり、最初のテーブルと同じ主キーと追加の列を持つ別のテーブルがあります。これは、自然なグループ化を形成する複数の異なる列がある場合に役立ちます。

要するに、原則として（c）を使います。パフォーマンスへの影響を最小限に抑えながら、データベースのリレーショナル整合性を維持します。（a）または（d）を使用する場合もありますが、それは問題と「最良」と見なされるものによって異なります。

于 2013-01-21T14:22:49.170 に答える
0

オブジェクトのリレーショナルデータベースへのマッピングに関するトピック、特に戦略の比較に関するセクションに関するScottAmblerのクラスペーパーをご覧ください。

http://www.agiledata.org/essays/mappingObjects.html#ComparingTheStrategies

于 2013-01-21T14:23:52.073 に答える