LLBLGenを使用してモデルを生成しますが、組み込みの継承ツールを使用するだけで設計の問題を解決したくはありません。OR/Mツールに関係なくモデルに意味を持たせたい。
したがって、アドレスを持つことができるいくつかの異なる種類のエンティティがあり、各エンティティは複数のアドレスを持つことができます（プライマリ、メーリングなど）。
オプション1は、スーパータイプ/サブタイプを使用しています（この種のスキームの正確な名前がわかっている場合は、それが役立ちます）
テーブル：EntityType [EntityTypeID、EntityTypeName]（Say、Company = 1、Employee = 2、AnotherEntity = 3）
エンティティ：[EntityID、EntityTypeID、OriginID]：EntityTypeID => EntityType
会社：[CompanyID、CompanyName、...]
従業員：[EmployeeID、FirstName、...]
AddressType：[AddressTypeID、AddressTypeName]（Say、Primary = 1、Mailing = 2など）
アドレス：[AddressID、AddressTypeID、EntityID、StreetAddress1、...]：AddressTypeID => AddressType、EntityID => Entity
これが機能する方法は、会社または従業員を作成する前に、EntityTypeを適切に入力してEntityレコードを作成する必要があるということです。次に、会社または従業員が作成され、Entity.OriginIDが会社または従業員のIDに設定されます。これで、アドレスレコードは、EntityTypeIDとOriginIDを表示する具体的なエンティティに「関連付けられる」エンティティレコードに属します。
これに必要なすべての参加について少し心配しています。さらに、これが私のORMツール（LLBLGen）では不格好になるのではないかと少し心配しています。
オプション2、これはオプション1の一種のテイクです。おそらくもっと悪いと思いますが、それを含めると同じです。
テーブル：
EntityType：[EntityTypeID、EntityTypeName]（Say、Company = 1、Employee = 2、AnotherEntity = 3）
エンティティ：[EntityID、EntityTypeID]：EntityTypeID => EntityType
会社：[CompanyID、EntityID、CompanyName、...]：EntityID => Entity
従業員：[EmployeeID、EntityID、FirstName、...]：EntityID => Entity
AddressType：[AddressTypeID、AddressTypeName]（Say、Primary = 1、Mailing = 2など）
アドレス：[AddressID、AddressTypeID、EntityID、StreetAddress1、...] AddressTypeID => AddressType、EntityID => Entity
これはオプション1と同様に機能し、会社または従業員の場合、エンティティレコードが最初に作成され、EntityTypeが適切に設定されます。次に、CompanyまたはEmployeeレコードが作成され、以前に作成されたEntityレコードのEntityIDがCompanyまたはEmployeeレコード自体に設定されます。アドレスはエンティティ自体に関連付けられます。ただし、これはAddressレコードをCompanyおよびEmployeeレコードのように扱うため、奇妙に思えます。つまり、EntityIDを保持していますが、その参照は、CompanyテーブルおよびEmployeeテーブルでEntityIDが参照するものとは異なる意味を持ちます。
これは少し悪いようです。最初の問題とほぼ同じ問題がありますが、スキーマの直感性が低下することもあると思います。
どちらの場合も、CompanyテーブルなどのいくつかのUnique制約を使用する必要があります（EntityIDはCompanyテーブルで一意である必要があります）。ただし、会社と従業員のレコードが同じエンティティレコードを指さないようにするには、他のプログラムによるチェックを行う必要があります。LLBLGenのようなツールが、EntityTypeID値をインテリジェントに処理することにより、オプション1で「魔法」を実行できるかどうかはわかりません。
したがって、オプション3は単純です。
テーブル：
会社：[CompanyID、CompanyName、...]
従業員[EmployeeID、FirstName、...]
AddressType：[AddressTypeID、AddressTypeName]（Say、Primary = 1、Mailing = 2など）
CompanyAddress：[CompanyAddressID、AddressTypeID、CompanyID、StreetAddress1、...]：AddressTypeID => AddressType、CompanyID => Company
EmployeeAddress：[EmployeeAddressID、AddressTypeID、EmployeeID、StreetAddress1、...]：AddressTypeID => AddressType、EmployeeID => Employee
これにより、結合の処理がはるかに簡単になります。しかし、これは実際には実行可能ではないと思います。私にはたくさんの実体があります。私は多くのエンティティを持っているだけでなく、アドレスを持つことができる多くのエンティティを持っています。また、この「アドレス」はほんの一例です。アドレスに似たものが他にもたくさんあります。これらすべての人のためにテーブルを作成することは、開発の面で非常に拡大するとは思いません。また、ORMにコードを使用して、すべての異なるアドレスを同じベース「アドレス」タイプとして処理させることができると確信していますが、ORMが実行できるトリックに依存したくありません。
それで、このスーパータイプ/サブタイプのものは良い考えですか（私はそうではないと思います）？もしそうなら、それについて行くより良い方法はありますか？そうでない場合、より良い選択肢は何ですか。