1

珍しいデータベース設計の問題があります。適切に処理する方法がわかりません。profileWebサイトユーザーの公開プロファイル情報を格納するというテーブルがあります。ただし、すべてのプロファイルは1人またはカップルのいずれかに属する可能性があるため、person個人固有のデータを格納するために呼び出される追加の子テーブルが必要です。すべてのprofileエンティティには、少なくとも1つ、ただし2つ以下のperson子エンティティが必要です。

そのような関係をモデル化するための最良の（「コーシャ」および/またはパフォーマンスの観点から）方法は何ですか？通常の1対多で、プログラムで、またはストアドプロシージャを使用して、子の数を強制する必要がありますか？または、親テーブルに2つの外部キーフィールドを作成しnull、そのうちの1つを許可する必要がありますか？多分私が考えることができない別の方法がありますか？

編集：ゴードンの質問に答える追加情報

  • 人は1つのプロファイルにのみ関連付けることができ、プロファイルのない人は存在できません。おそらく名前personは紛らわしいです。それは、人がプロフィールを持っていることを示唆しているかもしれませんが、実際には、人の情報を持っているのはプロフィールです。
  • カップルのプロフィールの場合、両方の人は平等です。サイト固有の理由により、2の制限は変更されませんが、人を追加または削除することは可能です（1人のプロファイルをカップルのプロファイルにする、またはその逆）。ただし、1未満または1を超えることはできません。 2名様。
  • 個人データはプロファイルデータなしでは取得されませんが、プロファイルデータは個人データなしで取得される場合があります。
4

2 に答える 2

4

1)

2 つのフィールドを持つソリューション:

  • PRO: プロファイルごとの最小人数と最大人数の両方を正確に制限できます。
  • 短所: プロファイルのない人を許可します。
  • 短所: 特定の人物のプロファイルを効率的に取得するには 2 つのインデックス (各フィールドに 1 つ) が必要であり、追加のスペースが必要になり、INSERT/UPDATE/DELETE が遅くなる可能性があります。

2)

ただし、アプリケーション レベルで最小数を強制する場合は、次のようにしたほうがよい場合があります。

ここに画像の説明を入力

CHECK(PERSON_NO = 1 OR PERSON_NO = 2)

特徴:

  • 短所: 人のいないプロファイルを許可します。
  • PRO: プロファイルごとの最大人数を制限しますが、CHECK を変更するだけで簡単に変更できます。
  • PRO: 上記のように識別関係を維持する場合、追加のインデックスは必要なく、クラスタリングに適しています(同じプロファイルの人を物理的に近くに格納できるため、JOIN 中の I/O を最小限に抑えることができます)。

一方、キー PERSON_ID (または同様のもの) がある場合、これらのフィールドにもキー制約を効率的に適用するには、{PROFILE_ID, PERSON_NO} に追加のインデックスが必要になります。

3)

理論的には、2 つのアプローチを組み合わせて、プロファイルのない人物と人物のないプロファイルの両方を回避することもできます。

ここに画像の説明を入力

(PERSON1_ID は NULL 不可、PERSON2_ID は NULL 可)

ただし、これは循環参照につながり、遅延制約を解決する必要があり、残念ながら MySQL ではサポートされていません。

4)

そして最後に、強引なアプローチを取り、単純に両方の人のフィールドをプロファイル テーブルに配置することができます (そして、これらのセットの 1 つを NULL 不可にし、もう 1 つを NULL 可にします)。

これらすべての可能性のうち、私はおそらく 2) を選びます。

于 2012-07-23T13:53:38.087 に答える
1

質問で述べたように、基本的に2つのオプションがあります。テーブルには 2 つのフィールドを格納できます。または、マッピング情報を持つ 2 番目のテーブルを持つことができます。

質問に答えるのに役立つ追加の質問を次に示します。

  • 個人が自分のプロフィールとカップルの一部としてプロフィールを持つことはできますか?
  • プロファイル上の両方の人が「同等」ですか、それとも一方が「マスター」でもう一方が「代替」ですか?
  • プロフィール情報を取得するとき、プロフィール上のすべての人に関する情報を常に含めますか?
  • プロフィールのない人を入れることはできますか?

この場合、「2」の制限が将来変更される可能性があるという卑劣な疑いがあります。フィールドを追加して「2」を増やすことは、既存のコードを変更するという点で問題になるため、別のテーブルにマッピングを格納することをお勧めします。つまり、個人をプロファイルにマップする個別のテーブル個人プロファイルを作成します。mysql では、GROUP_CONCAT() を使用して個人レベルの情報をいつでも収集できます。

このような同様のフィールドを同じテーブルに配置する方がよいケースの 1 つは、一方が明らかに優先され、もう一方が代替である場合です。その場合、多くの「coalesce(,)」タイプのロジックを実行しています。

于 2012-07-22T14:49:02.733 に答える