0

これを行うための最良の方法とその理由は何ですか?

ここに私のデータベース設計の一部を簡単に示します。このデータを整理する最良の方法を探しています。

"Leads" has many "Students", Leads has many "Contacts"

"Students" belongs to "Leads" and belongs to "People"
   id, person_id, lead_id

"Contacts" belongs to "Leads" and belongs to "People"
   id, person_id, lead_id

どの連絡先が「支払人」になるか、また連絡先が主要な連絡先になるかどうかを示したいと考えています。

最初は、次のようなテーブルをさらに 2 つ追加すると思っていました。

"PrimaryContacts" belongs to "Contacts"
   id, contact_id
"Payer" belongs to "Contacts"
   id, contact_id

次に、このような最初の Contacts テーブルで簡単に表現できるものを使用して、さらに 2 つのテーブルを追加するのは、やり過ぎのように思えることに気付きました。

"Contacts"
  id, person_id, lead_id, type, payer

次に、type を 1 または 2 にして、プライマリまたはセカンダリを意味し、payer フィールドを 1 または 2 にして、支払っているか支払っていないかを意味します。

いずれかの方法でそれを行う利点はありますか、それともまったく問題ではありませんか?

ありがとう！

4

1 に答える 1

1

私はあなたの要件に少し混乱していることを認めなければなりませんが、あなたの言うことを文字通り解釈すると、次のデータベースモデルにつながるようです:

ここに画像の説明を入力

フラグを使用すると、Contacts.payerプライマリ ステータスに関係なく、任意の数の支払人を持つことができます。

Payerこの場合、別のテーブルは必要ありません。

はLeads.primary_contact_idに対する NULL 可能な FKContactsです。これにより、リードごとに 0 または 1 つのプライマリ コンタクトを持つことができます (プライマリ コンタクトが 0 になる可能性を回避するには、NOT NULL が必要ですが、これは挿入サイクルにつながります。これは、MySQL ではサポートされていない遅延制約によって解決する必要があります)。

ただし、これは一次連絡先がそれ自体のリードに属していることを保証するものではありません (つまり、一致する場合でもContacts.lead_id異なる可能性があります)。問題ありますか？はいの場合、関係と複合 PK を識別する自由なアプリケーションが必要になりますが、これは ORM にとって問題になる可能性があります。Leads.lead_idContacts.contact_idLeads.contact_id

個別PrimaryContactsのテーブルは と非常によく似た効果がありLeads.primary_contact_id(PK が正しいと仮定すると)、一次連絡先が 0 でリードの不一致が許容されるという同じ問題さえあります。データベースの観点からは、「後方」の FK を使用する方が単純で効率的です (ただし、CakePHP の観点から見て、それが依然として正しいかどうかはわかりません)。

残念ながら、私は CakePHP に詳しくありません。このモデルを自分で「翻訳」できることを願っています。

于 2012-07-17T20:34:34.030 に答える