1

学生エンティティがあります。次に、のような学生テーブルと学生属性テーブルを作成しますdob, age, salary。学生の属性は約120です。

したがって、テーブルのパフォーマンスとMySQLの操作に関してはどちらが将来的に良くなるでしょうか

オプション

  1. すべてのstudent属性を適切なデータ型の列として持つ1つのテーブル（student_mst）を作成します

  2. または、リレーションを使用して2つのテーブル（student_mst, student_attributes）を作成し、学生属性の複数のレコードをに追加します。table - student_attributes.

4

4 に答える 4

1

これらは2つの完全に異なるアプローチであるため、データをどのように処理するかによって完全に異なります。パフォーマンスが問題になるのは、データへのアクセス方法がうまく機能しないモデルを選択した場合のみです。

最初のオプションは、すべての学生がすべてまたはほとんどの属性を使用し、属性の固定セットがある場合の自然なアプローチです。

2番目のオプションは、学生が異なる属性のセットを持っていて、属性のセットを拡張する可能性が高い場合に役立ちます。

最初のアプローチでは、通常、さまざまな属性を処理するためにさまざまなクエリを記述します。たとえば、学生のリストを取得して、いくつかの属性を返すのは簡単です。例：

 select StudentId, Name, Age, Class, Grade
 from Students
 order by Age desc

2番目のアプローチでは、通常、基本的な学生情報と学生属性を別々に取得します。いくつかの属性を持つ学生のリストを取得することはより複雑であり、取得したいより多くの属性を構築します。例：

 select s.StudentId, Name = a1.Value, Age = a2.Value, Class = a3.Value, Grade = a4.Value
 from Students s
 inner join Attributes a1 on a1.StudentId = s.StudentId
 inner join Attributes a2 on a2.StudentId = s.StudentId
 inner join Attributes a2 on a3.StudentId = s.StudentId
 inner join Attributes a3 on a4.StudentId = s.StudentId
 order by cast(a.Value as int) desc
于 2012-10-28T10:51:43.077 に答える
0

一般に、リレーショナル データベースでのコストのかかる操作は、データセットの "行" を回復することです。列によってもフィルタリングできることは、最終的なデータセットをより適切に調整するための構文糖として提供されます。したがって、行間の関係を調整する方法を最適化するようにしてください。列の数は検索パフォーマンスには影響しないため、あまり気にしませんが、主に「ネットワーク上を移動するデータの量」 " .

于 2012-10-28T11:03:20.580 に答える
0

一般に、テーブルの列構成をデータの論理構造に基づいて決定し、インデックスなどの物理的な設計機能に依存して高速化することをお勧めします。

学生の属性が学生テーブルに属するかどうかは、ほとんどの場合、すべての学生がこの属性を持っているのか、それとも一部の学生だけが持っているのかという問題です。すべての生徒が属性を持っている場合、属性を生徒テーブルに保持する方が、取得時に結合を行うよりも通常は高速になります。それは論理的なアプローチでもあります。

一方、特定の学生にのみ関連する属性がある場合は、ケースを分析して、学生の特殊なサブセットを扱っているかどうかを確認する必要があります。これが実際に当てはまる場合は、「ER Specializaton」を調べて、これを概念レベルでモデル化する方法を確認する必要があります。

リレーショナル デザインで特殊化のケースを実装する方法を知りたい場合は、「クラス テーブルの継承」を参照してください。

于 2012-10-28T17:26:16.757 に答える
0

@Guffaによる回答に加えて、さらにいくつかの考慮事項

関連する属性テーブルに行く場合。各生徒のすべての属性には、属性 ID と生徒 ID が必要です。たとえば、整数の場合は 8 バイトです。そのため、それらがどれほどまばらであるかを検討する価値があります。

120 の属性をグループ化できますか。一見の価値があるかもしれません。おそらく属性タイプ /group といくつかの 1 - 1 拡張テーブル。

学生とそのすべての属性を取得するだけでなく、属性を持つすべての学生を取得する場合。

クエリを実行する予定の属性がほとんどない場合は、残りの xml スニペットまたはシリアル化されたオブジェクトを検討する価値があります。

最後に、複雑な結合クエリ (120 個も実行したくないでしょう :) )

代わりにそれらをピボットすることも、1 つの結合を 2 つの列として元に戻すこともできます。これは、UI をどのようにマッピングするかに明確な影響を与えます。

これに対する正しい答えはありませんが、スキーマ全体に SQL をばらまくのではなく、いくつかのメソッドの背後にスキーマを隠す場合は、実際には設計で確定しなければならないものではありません。

于 2012-10-28T11:17:24.787 に答える