0

（これは重複している可能性が高いことは認識していますが、検索に基づいて回答が見つかりません）

ユーザーまたは会社に参加できる情報を含むテーブルがあります。この問題を解決するには、次の 3 つの方法があります。

  1. テーブルに join_user_id 列と join_company_id 列を指定し、2 つのうちの 1 つだけを入力します。
  2. join_id 列と joins_with_table 列を作成します
  3. メイン テーブルを複製して、2 つのバージョン (1 つは join_user_id のみ、もう 1 つは join_company_id のみ) が存在するようにします。

乾燥していないので、すぐに 3 を除外します。私の質問は、これらのうちどれが真に正規化された設計であるか (またはどれもでない) かということです。

次の欠点をどのように処理しますか? 2. 外部キー制約を適用するにはどうすればよいですか? 簡潔に参加するにはどうすればよいですか？

4

3 に答える 3

0

1つの列に値を設定すると、別の列（主キーではない）の値について何かがわかるため、1と2のどちらも第3正規形ではありません。これにより、3NFに必要な主キーに完全に依存するという特性が失われます。

外部キーを作成するのは難しい/不可能であり、列の値の意味について混乱を招く可能性があるため、オプション2は絶対に除外します。誰かがjoins_with_table列を変更せずに列を変更したjoin_id場合、あなたは知らないかもしれません！

これを3NFでモデル化するには、ユーザー用と企業用の2つの新しいテーブルを作成する必要があります。これらには、主キーとしてのoriginal_table_id, user_id（または会社）があります。original_table_id次に、一方のテーブルまたはもう一方のテーブルにエントリしかないことを検証する必要があります。

個人的には、これらを元のテーブルの追加の列として検討することを検討しますが、条件付きで参照する必要のあるテーブルをさらに追加する可能性が高いと思われる場合を除きます。nullを回避するように設計するべきではないので、これについて心配する必要はありません。このソリューションと追加のテーブルアプローチはどちらも、このテーブルの会社とユーザーの両方に関する情報を返す必要がある場合はuser、テーブルへの外部結合を必要とするため、クエリの複雑さに実際の違いはありません。company

于 2013-01-07T20:26:09.400 に答える
0

これがベスト プラクティスであると主張しているわけではありませんし、あなたの状況でうまくいくとしても、4 番目のオプションは、共通の列userとcompanyテーブルを別のテーブルに保持することです (おそらくuser_comp_base)。ユーザーと会社の詳細は、テーブルと同じキーを持つ別のテーブルに入れることができuser_detailsますcompany_details(user_company_baseオプションで、この行の詳細がどのテーブルに含まれているかを示す列も含まれる場合があります)。

join_id_user_comp_base次に、外部キー制約と簡潔な結合の問題を解決するテーブルが必要です。もちろん、詳細が必要な場合、これには別のテーブル ( user_detailsOR )との結合という代償が伴います。comp_details

編集：この概念はテーブル継承と呼ばれると思います。

于 2013-01-07T19:16:27.917 に答える
0

これらのうち、真に正規化された設計である (またはいずれでもない) のはどれですか?

それらはすべて「正規化」されていますが、すべてが同じように役立つわけではありません。

1) 空っぽをたくさん残すと、きれいに成長しません。

NULL は、ほとんどの DBMS でかなり効率的に格納されます。通常は 1 バイト、または理想的な環境下の一部の DBMS ではわずか 1 ビットです。

CHECK を使用して、そのうちの 1 つだけが非 NULL であることを確認できます。

2) 外部キー制約を強制するにはどうすればよいですか?

理論的には、FK を下に移行joins_with_tableしてから、参照テーブルに CHECK を設定して、適切な型を確保することができます。明らかに、これは扱いにくく、スペースを浪費します (DBMS が計算列/仮想列をサポートしていない場合)。

トリガーまたは (絶対に禁じられている) アプリケーション ロジックに依存することもできますが、単純さ、堅牢性、および速度のために、可能な限り宣言型の制約を優先する必要があります。

乾燥していないので、すぐに 3 を除外します。

残念ながら、リレーショナル データベースは多くの場合、OO プログラミングで慣れ親しんだ概念をサポートしていないため、結果として不必要な繰り返しが発生する可能性があります。たとえば、テーブルの継承 (ベース テーブルが「構造」を定義し、子が特定の FK を定義する) は、この場合の繰り返しを軽減するのに理想的です。

現状では、バランスを崩さない限り、いくつかの繰り返しは世界で最悪のことではありません.

簡潔に参加するにはどうすればよいですか？

あなたの質問がよくわかりません。明確にしてください。必要に応じて、JOIN は、テーブルのデザインだけでなく、キーのデザインによっても大きく影響を受ける可能性があります。

全体として、(3) を正当化する可能性のある他の違いが予想されない限り、私はおそらく (1) を使用します。

于 2013-01-09T00:29:59.460 に答える