友人のローン データベースをモデル化しています。
顧客は、0 から N 個の 住所(番地または私書箱の住所、または複数の番地と私書箱の住所)を持つことができます。PropertyにはAddressを 1 つだけ指定する必要があります。Company (雇用情報) にはAddressが1つだけ必要です。
Customersテーブル用に別のAddressesテーブルを用意することをお勧めします。物件と会社の住所は、物件と会社のテーブルと一緒に使用できます。
しかし、ここにはAddressesテーブルがあるので、そのAddressesテーブルをCompanyテーブルとPropertiesテーブルにも共有するのは良い考えだと思いますか?
物同士の関係を考えるとき、ある時点を切り取る（静的？）か、一定の時間範囲を見て（動的？）関係を分析する？たとえば、会社は特定の時点で 1 つの住所しか持つことができませんが、その会社は最近ある場所から別の場所に移動した可能性があります。次に、会社は特定の期間に複数の住所を持つ場合があります。
あなたがローンを組んでいるので、あなたは彼らの住所がどこにあるか知りたいかもしれないので、顧客は0からNの関係よりも1からNの方が良いでしょう。
会社（雇用情報）の住所は1つだけです。
その場合、会社は特定の期間に複数の住所を持っている可能性があります。
あなたは少し矛盾していますが、なぜ2つのアドレスが必要なのですか？新しいアドレスですべてを取得するまで、会社の公式アドレスは1つだけになると思います。その時点で、DBを新しいアドレスに更新できます。
ただし、ここにAddressesテーブルがあるので、CompaniesテーブルとPropertiesテーブルのAddressesテーブルも共有しないのは良い考えだと思いますか？
はい
そして、ここにモデリングに関するいくつかのアイデアとの素晴らしいリンクがあります：
会社 (雇用情報) には、住所が 1 つだけ必要です。
必ずしも。会社は、郵送先住所と物理的な住所を持つことができます。
ここに Addresses テーブルがあるので、その Addresses テーブルを Company テーブルと Properties テーブルにも共有するのは良い考えだと思いますか?
はい、Addresses テーブルに住所を入れることをお勧めします。Properties テーブルには住所行の外部キーがあり、Company テーブルには 2 つの外部キーがあり、1 つは郵送先住所用で、もう 1 つは住所用です。郵送先住所は、オプションの (null 許容の) 外部キーになります。
Customer と Address の間の 0 対 N の関係を維持するには、CustomerAddress テーブルが必要です。必要に応じて、Address と Customer の間に 0 対 N の関係を持つこともできます。
テーブルはこのようになります。
CustomerAddress
---------------
CustomerAddress ID
Customer ID
Address ID
CustomerAddress ID は、プライマリ (クラスタリング) インデックスです。昇順の整数または長整数、またはその他の一意の ID です。
固有の indexon (顧客 ID、住所 ID) が作成されます。
住所を顧客に関連付ける場合は、(住所 ID、顧客 ID) に別の一意のインデックスを作成します。
会社は特定の時点で 1 つの住所しか持つことができませんが、その会社は最近ある場所から別の場所に移動した可能性があります。次に、会社は特定の期間に複数の住所を持つ場合があります。
この情報が重要な場合は、CompanyAddress テーブルに日付の列を含める必要があります。(企業 ID、日付の降順) に一意のインデックスを作成します。このようにして、Address テーブルから取得する最初の行が最新の住所になります。
すべてのアドレスを独自のテーブルに入れるというのは、非常に一般的なアイデアのようです。開発者は繰り返しを探し出し、それを排除するのが大好きです。しかし、この場合、アドレスを独自の専用テーブルに配置してエンティティ ステータスで威厳を持たせることを躊躇します。なぜなら、ほとんどのアプリケーションと同様に、アドレスを本格的なエンティティとして扱わないと、複雑になりすぎるからです。
住所を実際のエンティティとして扱った場合、2 つの会社が何らかの形で同じ住所を共有した場合、または 1 つの会社がしばらくの間ある場所に住んでいた場合、別の会社が同じ場所に住んでいた場合、それらの会社は同じ住所を参照します。アプリケーションが入力としてアドレスを受け入れていた場合、アドレス テーブルにガベージを叩きつけるだけでなく、既存のアドレスがあるかどうかを確認して参照するためです。どちらにするつもりですか？ほとんどのビジネス アプリケーションと同様に、入力している新しいアドレスがデータベースに既に存在する他のアドレスと同じであるかどうかをまったく気にしないため、問題はありません。個々のものとして扱います。それがエンティティとキャットフードの違いです。
したがって、統合では、交差テーブルを導入してインデックスを作成する必要があり、アドレスを持つすべてのエンティティをそれに結合する必要があります。アドレスを熱心に取得するか、遅延読み込みを使用するかを検討する必要があります。すべてのアドレスを 1 つのバケットにまとめ、誰もが自分のアドレスにすばやくアクセスできるようにする必要があります。実際のエンティティの場合、異なるものが同じエンティティにリンクする必要があるため、これはある程度理にかなっていますが、それを気にしないことを上記で確立しました。誰もこれらのエントリを共有していません。
アドレスを 1 つのテーブルに統合することで排除している繰り返しはどこにあるのでしょうか? 住所はどこかに関係なく、同じフィールドを使用してデータベースに格納されるため、スペースを節約できません。唯一の繰り返しは、スキーマを生成するために使用される DDL にあります。これは、アドレス (アプリケーション コードの冗長性に対処する) の再利用可能なコンポーネント (「コンポーネント」は Hibernate 用語) を作成し、ORM ツールを使用して管理できます。スキーマを生成します。または、最悪の場合、それを無視してください。アドレスはそれほど変更されません。それはあなたの最大の問題ではありません。
あなたが説明しているこれらの要件は、あなたが友人のために行っているプロジェクトにとって、疑わしいエンタープライズのように聞こえます。おそらく、あなたの友人の脳は、委員会が何をしているのかを知らない委員会によってでっち上げられた要件を精巧に説明するために過度に露出することによって毒されている. 仕事でこのがらくたを我慢しなければならないのは十分に悪いことですが、個人的なプロジェクトの場合はどうですか? 彼を説得してみてください。
しかし、あなたの友人が企業的な仕事をあなたにアウトソーシングしているかもしれません。もしそうなら、被害を封じ込めてください: 顧客の住所専用のテーブルを作成して、交差テーブルを必要としないようにし、他のエンティティの住所をインラインに配置します。アドレスが 1 つしかないこれらのエンティティを別のテーブルからアドレスを取得しても、結合が増えるだけです。履歴が必要な場合は、邪魔にならない別の履歴テーブルに書き込みます。