0

次のエンティティがあるとしましょう: 顧客、アカウント、契約、サブ契約、サブ契約アカウント。

顧客は 0 個以上のアカウントを所有しており、顧客は 0 個以上の契約を持っています。各契約には、顧客がアクセスできる特定のタイプのすべてのアカウントがあります。顧客は自分のアカウント以外にもアクセスできるため、顧客がアクセスできるすべてのアカウント (アカウントの種類を含む) を取得するビューがあります。

契約には特定のタイプのアカウントがあるため、特定の契約のすべてのアカウントを簡単に照会できる新しいビューが必要です (基本的には最初のビューを使用しますが、契約のアカウントの種類と結合します)。

その後、顧客は契約をベースとしてサブ契約を作成できます。そのため、顧客は、基本契約にあるアカウントの一部のサブセットを使用してサブ契約を作成することを選択できます (サブ契約アカウント)。ここでは、基本契約に含まれていないサブ契約にアカウントが挿入されるのを防ぐために、基本契約のアカウントへの外部キーが必要です。しかし、それはビューだけなので、それは不可能です!

外部キーをスキップし、アプリケーション ロジック (および、アカウントとサブ契約アカウントの間の外部キーも) を使用して、ベースにないサブ契約にアカウントを挿入できないようにする必要があります。合意?または、「契約アカウント」テーブルを導入して、契約のアカウントを取得し、アプリケーションでそのテーブルを維持するのに役立つビューを具体化する必要がありますか?

4

1 に答える 1

0

(時折)関係制約を強制するために余分なテーブルを作成することは決してありません。
必ず、アカウントと契約の間に自然な関係/制約を作成しますが、時折使用するために余分なデータの複雑さを導入しないでください。
サブ契約を作成する時点で、基本契約に有効なアカウントのサブセットをユーザーに提示し、保存時に選択したリストを再確認します。

于 2012-08-13T14:05:55.430 に答える