1

他のいくつかの異なるエンティティ タイプに関連付けたい汎用エンティティを持つデータベースを設計するためのアドバイスを探しています。恐ろしいイントロ文、私は知っています...それで例を挙げて説明させてください。

テーブル定義を持つ 2 つの異なるエンティティ Employees と Customers があるとします。

Employees
----------
EmployeeID int PK
FirstName varchar
LastName varchar
... other Employee specific fields

Customers
----------
CustomerID int PK
FirstName varchar
LastName varchar
... other Customer specific fields

より良い設計では、関連するベース テーブルに FirstName と LastName という共通のフィールドを含めることができますが、それは私が苦労している部分ではありません。

ここで、Employees と Customers の Addresses と PhoneNumbers を無制限に格納できるようにしたいと考え、テーブルを定義します。

Addresses
----------
AddressID int PK
AddressLine varchar
City varchar
State varchar
PostalCode varchar

PhoneNumbers
-------------
PhoneNumberID int PK
PhoneNumber varchar
PhoneExtension varchar

次に、Addresses と PhoneNumbers を Employees に関連付ける 2 つの追加テーブル:

EmployeeAddresses
------------------
EmployeeAddressID int PK
EmployeeID int FK Employees.EmployeeID
AddressID int FK Addresses.AddressID
EmployeeAddressType enum

EmployeePhoneNumbers
---------------------
EmployeePhoneNumberID int PK
EmployeeID int FK Employees.EmployeeID
PhoneNumberID int FK PhoneNumbers.PhoneNumberID
EmployeePhoneNumberType enum

同様の 2 つのテーブル、CustomerAddresses と CustomerPhoneNumbers は、Addresses と PhoneNumbers を Customers テーブルに関連付けます。上記の EmployeeAddressType のような Addresses および PhoneNumbers の従業員固有または顧客固有の側面も、これらの最後の 4 つのテーブルに含まれます。

インターネットで調べたところ、この設計は Table-Per-Type (TPT) または Table-Per-Subclass (TPS) と呼ばれています。また、ポリモーフィックの利点は魅力的に思えます。たとえば、AddressLine2 を Addresses テーブルに後で追加すると、Employess と Customers の両方が追加の住所行の利点を自動的に得ることができます。

TPT に関するこれらの情報源が指摘している欠点は、クエリ速度が遅く、実装が難しいことです。そして今、アドバイスを求める私のかなり自由な嘆願...

私が考慮していない他の欠点は何ですか？この設計に基づいてアプリケーションを維持および進化させようとすると、どのような問題に遭遇する可能性がありますか? 最後に、上記の設計は、経験豊富なデータベース設計者が使用するものでしょうか?

ありがとう。

4

4 に答える 4

1

  1. 単一テーブルの継承を使用して開始します。それは最も簡単で、簡単で、最速です。

  2. パーティモデルを採用。個人と組織はどちらも当事者であり、顧客または従業員の役割を果たすことができます。

  3. 電子メール アドレス、電話番号、Web サイト、および郵送先住所はすべて、「連絡方法」または住所のサブタイプであると考えてください。

  4. JBoss Hibernate (java) や NHibernate (.net) などのツールを使用すると、ほとんどの作業はこれで完了します。

于 2013-04-26T17:10:07.733 に答える
0

People テーブルから始めて、customers テーブル、employees テーブルなどを作成する方がはるかに優れています。電子メール アドレス、住所、電話番号は、customer テーブルやその他の特別なテーブルではなく、people テーブルに関連付けられます。

複数の親テーブルに関連する 1 つのアドレス テーブルの問題は、適切な外部キー制約を設定できず、常に不良データになってしまうことです。

別のテーブルを使用して外部キーを適切に作成できますが、クエリが難しくなり (CA の全員を知る必要があるとします)、複数のカテゴリ (従業員も顧客である可能性があります) に属する人々の重複レコードが取得されます。テーブル構造を変更する必要が生じたときに、テーブルがすべて更新されていることを確認するのが難しくなります。

于 2013-04-26T18:26:50.377 に答える
0

前の回答で述べたように、Employees と Customers はどちらもクラス People のサブクラスです。これら 2 つのサブクラスは、相互に排他的ではない場合があります。

クラステーブルの継承と呼ばれる手法があります。この手法では、People、Employees、Customers の 3 つのテーブルが作成されます。住所など、すべての人に共通の属性は、People テーブルに含まれます。

このタグ にアクセスし、「Info」タグの下を見ると、詳細を取得できます。

于 2013-04-26T19:34:58.080 に答える