8

約1,000レコードのテーブルがあります。それらの約半分は、特定の特性を含む一連のフィールドを利用します。関連するフィールドは約 10 です。レコードの残りの半分には、その情報を入力する必要はありません。

このテーブルはデータベースの中心であり、操作の大部分を占めます。1,000 レコードほどしかありませんが、それほど多くはありません。

データベースが保存されているハードウェアは古くて遅い (SSD ではなく回転するハード ドライブ...) ので、それを最大限に活用するためにかなり最適化された構造が必要です。明らかに、空のフィールドが原因でデータベースのサイズが大きくなることだけは大きな懸念事項ではありませんが、クエリの速度が低下している場合、それは良くありません。

設定を説明する必要があると思います。現在、Access 2007 クライアントと Access バックエンドですが、バックエンドはまもなく SQL サーバーに移行します。現在、バックエンドはメイン サーバー ラックにありますが、SQL Server に移行すると、独自の古いサーバー ラックになります。

では、前述の一連の特性を格納する別のテーブルを作成する必要がありますか、それともそのままにしておく必要がありますか?

4

3 に答える 3

6

オプションのフィールドを別のテーブルに配置してから結合を使用するというクエリのオーバーヘッドは、サイズやデータ管理に大きなメリットをもたらしません。特にあなたの例のように1対1の場合。サイズについては、オプションのフィールドは NULL になり、あまり影響はありません。はい、75% は、移動を開始する必要がある場合の適切なランダムしきい値ですが、それでも、オプションのフィールドを移動することによって実際には何も正規化していません (それらがレコードと 1 対 1 であり、常にメインレコードと一緒に取得します)。

注目に値する: ほとんどの DB では、単一のクエリで大きな行を取得する方が、いくつかの小さなクエリよりも優れています...後で別のクエリで 2 番目のテーブルのオプションのデータを取得する必要がある場合に備えて。ただし、Access 2007 では、これはあまり重要ではありません。

オプションのフィールドを移動するかどうかに関係なく、where/ having/で使用できるフィールドのインデックスを追加しますjoin。

于 2012-08-27T07:45:46.080 に答える
1

あなたが言ったことからの私の印象は、別のテーブルを使用する必要があるということです。表現したい依存関係とデータ整合性の必要性 (「ビジネス ルール」) によって、属性がどのテーブルに入るかが決まります。

あなたの場合、2 種類の事実を表す必要があるように思えます。これらのファクト タイプには個別の属性セットがあるため、異なるテーブルに属します。2 つの異なるファクト タイプを 1 つのテーブルに結合し、1 つの属性セットを null 可能にする場合、データの整合性が損なわれる可能性があります。つまり、ビジネス ルールでそのような値が必要ない場合に一部の属性の値を許可し、ビジネス ルールで値が存在しないことを許可することにより、データの整合性が損なわれる可能性があります。実際にそれを必要とします。

これに答えるより正式な方法については、第 5 正規形と直交設計の原則を参照してください。これらの設計原則をまだ認識していない場合は、それらに精通する必要があります。

于 2012-08-27T09:40:51.393 に答える
0

キャッシュをより効率的にするために、大規模なデータ セットには垂直分割が適しています。かなり古いハードウェアであっても、1000 行は「大きい」とは見なされません。

したがって、このテーブルを再設計する他の理由がない限り (ルックアップをマージしていませんか?)、問題ありません。

于 2012-08-27T10:31:24.057 に答える