1

データベースに次のエンティティを持つ既存のアプリケーションがあります

  • お客様
  • 請求書グループ
  • セールスグループ

顧客は、複数のグループの一部になることができます。現在、これは次のようにマッピングされています

Customer table
 - cid (Pk)
 - fname
 - surname
 ----
 ---
 - invgrpdid (Fk)
 - salesid (Fk)

Invoicegroup table
 - invgrpid (Pk)
 - name
 - type
 ---
 ----

Salesgroup table
 - salesid (Pk)
 - name
 - desc
 -----
 -----

新しいエンティティ キャンペーンを追加する必要があります。顧客は、複数のキャンペーンの一部になることができます。個々の顧客を選択する (カスタム) または - 既存の請求書グループを選択する (請求書) または - 既存の販売グループを選択する (販売) ことによって作成される顧客グループに対して、キャンペーンが展開されます。

キャンペーンの顧客リストは - 再利用可能、つまり複数のキャンペーンに使用できる - 動的、つまり請求書/販売グループから作成された場合、請求書と販売グループ全体の変更はキャンペーンの顧客リストに反映される必要があります

動的要件の設計に苦労しています。私は次の設計を考え出しましたが、複数の外部キーを参照する 1 つのキーである排他的なアークがあり、推奨されるアプローチではありません。スーパータイプとサブタイプについて考えましたが、多対多の関係の設計については明確ではありません。

campaign
 - campaignid(Pk)
 - name
 - startdate
 - status
 ------

campaignlist
 - listid(Pk)
 - listname
 - listtype - Invoice, Sales, Custom
 - typeid (Fk) - Refers to invoicegroupid or salesgroupid depending on listtype
 -----

customercampaign
  - listid (Fk)
  - customerid (Fk)
  - status
  - dateupdated
  -------------

参照整合性と正規化を考慮して、これを設計するためのより良いアプローチは何でしょうか。1 日に複数回実行される最も頻繁なクエリは、顧客のすべてのキャンペーン情報を取得することです。そのため、複数のテーブルと結合に注意する必要があります。

4

1 に答える 1

1

最初の刺し傷で、私は次のようなことをします：

CampaignList
    - ID (PK)
    - Name

CustomerCampaignList
    - CampaignListID (FK to CampaignList.ID)
    - CustomerID (FK)
      UNIQUE (CampaignListID, CustomerID)

SalesGroupCampaignList
    - CampaignListID (PK,FK to CampaignList.ID)
    - SalesGroupID (FK)
      UNIQUE (CampaignListID, SalesGroupID)

InvoiceGroupCampaignList
    - CampaignListID (PK,FK to CampaignList.ID)
    - InvoiceGroupID (FK)
      UNIQUE (CampaignListID, InvoiceGroupID)

つまり、テーブル継承を使用します。これは非常に標準化された設計であり、私の意見では、特定の要件についてまだ理解していない場合に取るべきアプローチです。CampaignListTypeID必要に応じて、少し非正規化し、表に a を入れることで、生活を楽にすることができCampaignListます。ただし、この場合、トリガーにロジックを記述せずにデータ モデルの整合性を維持することは困難です。

興味深い組み合わせグループを作成する必要はないと思います。たとえば、2 x 販売グループ + 請求書グループ + 一連の顧客などです。

于 2012-06-07T05:36:58.943 に答える