2

データベースを設計していますが、どのアプローチを使用すればよいか迷っています。設計しようとしているデータベースと、データをテーブルに格納するために使用できるアプローチについて説明します。

どのアプローチを使用すべきか、またその理由を教えてください。

データについて:

A)私には、注意が必要な 7 つの属性があります。これらは単なる例であり、私が保存しようとしている実際のものではありません. 私はそれらを呼びましょう：

1)お名前

2)DOB (修正..以前ここに年齢を入れていた..)

3)性別

4)婚姻状況

5)給与

6)母国語

7)父の名前

B）テーブルには最低10000行あり、長期的にはそこから増加する可能性があります

C)属性の数は、時間の経過とともに変化する可能性があります。つまり、新しい属性を既存のデータセットに追加できます。属性が削除されることはありません。

アプローチ1

7つの属性を持つテーブルを作成し、データをそのまま格納します。新しい属性を追加する必要がある場合は、新しい列を追加しました。

  • 長所: データが読みやすく、情報が整理されている

  • 短所: 値が不明な特定の属性の特定の行に、多くの null 値が存在する可能性があります。

アプローチ 2

3 つの属性を持つテーブルを作成します。それらを呼びましょう：

1) Attr_Name : 属性名を格納します。例: 名前、年齢、性別など

2) Attr_Value : 上記の属性の値を格納します。例: Tom、25、Male

3) 一意の ID : データベース内の名前と値のペアを一意に識別します。例えば。SSN

したがって、アプローチ 2 では、特定の行に新しい属性を追加する必要がある場合に、作成したハッシュマップに属性を追加するだけで、null 値を気にする必要はありません。

  • 長所: ハッシュマップ構造。ヌルを排除します。

  • 短所: データが読みにくい。簡単に情報が掴めない。

C) 質問

どちらがより良いアプローチですか？

アプローチ1がより良いアプローチだと思います。null 値を処理するのはそれほど難しくなく、データは適切に整理されており、このデータの王様を簡単に把握できるためです。どのアプローチを使用すべきか、またその理由を教えてください。

ありがとう！

4

3 に答える 3

4

これは、典型的なナロー テーブル (属性ベース) とワイド テーブルの説明です。アプローチ 2 の問題点は、おそらくデータをピボットして、ユーザーが操作できる形式にする (ワイド ビュー形式に戻す) 必要があることです。これは、行数や属性数が増えるにつれて、リソースを大量に消費する可能性があります。また、生のテーブル ビューでテーブルを見て、何が起こっているのかを確認することも困難です。

この議論は、当社でも何度も行ってきました。属性タイプのスキーマに非常に適したテーブルがいくつかあります。データをピボットする必要があり、データを表示して意味を持たせることができないため、私たちは常にそれに反対することにしました (しかし、これは私たちにとって 2 つの問題の小さい方です - 何百万ものデータをピボットしたくないだけです)。行のデータ)。

ところで、私は年齢を数値として保存しません。生年月日があれば保存します。また、「母国語」が何を指しているのかはわかりませんが、それが母親が話す言語であれば、これをマスター言語テーブルへの FK として保存します。より効率的で、言語のスペルミスによる不良データの問題が軽減されます。

于 2013-08-13T17:34:17.140 に答える
3

2 番目のオプションは、起こり得る最悪の設計ミスの 1 つです。これは、絶え間なく変化し、オブジェクトごとにまったく同じではない何百もの属性がある場合にのみ実行する必要があります (医療ラボのテストなど)。それを行う必要がある場合は、どのような状況でもリレーショナル データベースを使用しないでください。NOSQL データベースは、リレーショナル デザインよりもはるかに優れた EAV デザインを処理します。

設計 2 のもう 1 つの問題は、FK とデータ型を正しく適用してデータに制約を追加することができないため、良好なデータ整合性を確保することがほとんど不可能になることです。アプリケーション以外のことがデータに影響を与えることが多いため、このようなことはアプリケーションでのみ発生するように設計されるべきではないため、この要因だけで2番目のアイデアを愚かで無謀なものにするのに十分です。

最初の設計は、一般的にパフォーマンスが向上します。必要かどうかにかかわらずすべての属性を常に表示するように設計するのではなく、クエリを作成する方が簡単で、属性を追加するときに何を変更する必要があるかを考える必要があります (これはマイナスではなくプラスです)。多数の null がある場合は、列を増やすのではなく、関連するテーブルを追加します (1 対 1 の関連テーブルを使用できます)。通常、この場合、レコードのサブセットのみが持つことがわかっているものを持っている可能性があり、それらは多くの場合、かなり自然に主題ごとにグループ分けされます。たとえば、1 つのテーブルに属している一般的な人関連の属性 (名前、電話、電子メール、住所) があるとします。次に、別のテーブルに属している学生関連の属性と、3 番目のテーブルに属している教師関連の属性がある場合があります。

3 番目の設計の可能性があります。前もって知っている一連の属性がある場合は、それらを 1 つのテーブルにまとめ、設計時に決定できない属性専用の EAV テーブルを作成します。これは、ユーザーが顧客固有のデータ フィールドを追加できる柔軟性をアプリケーションに持たせたい場合の一般的なパターンです。

于 2013-08-13T18:46:51.613 に答える
1

どちらが優れているかをすぐに判断できる人はいないと思いますが、次の点を考慮してください。

  1. サンプルデータはありますか？はいの場合は、多くのヌルがあるかどうかを確認します。ない場合は、オプション 1 を使用します。
  2. 属性がどのように成長するかについて、あなたは良い感覚を持っていますか? たとえば、上に挙げた属性を見ると、すべてを知っているわけではないかもしれませんが、すべて存在するので、理論的には表を埋めることができます。まばらなデータがたくさんある場合は、＃2が機能する可能性があります
  3. 新しいタイプのデータを取得したら、それを別のテーブルにグループ化し、外部キーを使用できますか? たとえば、アドレスをキャプチャしたい場合は、最初のテーブルを参照するアドレス テーブルを常に持つことができます。
  4. どのタイプのクエリを使用する予定ですか? 「通常のテーブル」よりもキーと値のテーブルをクエリするのははるかに困難です (非常に難しいというわけではなく、単に難しいだけです。暗黙の結合などを使用してデータを正規化することに慣れている場合は、おそらく大したことではありません)。

全体として、＃2を実装する前に非常に注意します-特定の特殊なケース（数十の異なるメトリックがあり、数十の異なるテーブルを実際に維持したくないメトリック収集）に対してそれを行いましたが、一般的にはもっと価値があるよりもトラブル。

このような場合は、1 つのテーブルを作成し、必要に応じて列を追加するか、新しいデータ構造用の新しいテーブルを作成します。

于 2013-08-13T17:41:32.650 に答える