5

私は、個人と会社の2つの主要なエンティティを持つ連絡先アプリケーションを作成しようとしています。人は多くの電子メール、番号、およびアドレスを持つことができます。会社はまた、多くの電子メール、番号、およびアドレスを持つことができます。このシナリオの適切な設計を決定しようとしています。

オプション＃1-複数の外部キー
電子メール、番号、およびアドレスには、person_idおよびcompany_idという2つの列があります。データが属するエンティティに応じて、一方はnullになり、もう一方には親にリンクするIDが含まれます。

オプション＃2-エンティティごとにタイプごとに1つのテーブル
各テーブルを複製して、company_addressesテーブルとperson_addressesテーブルを作成します。テーブルの数は2倍になりますが、これが現時点で最も理にかなっているソリューションです。

オプション＃3-1つのリンクテーブル
1つのテーブルを作成します-「リンク」。このテーブルには、source_id、source_entity、dest_id、dest_entityの4つの列が含まれます。したがって、会社が新しい番号を取得した場合、1、番号、2、会社のような行があります。

オプション＃4-複数のリンクテーブルリンク
の種類（company_address、person_address、company_email、person_emailなど）ごとにテーブルを作成します

どのオプションを選択しますか？

4

2 に答える 2

8

あなたは避けるべきだと私が主張するいくつかの慣行に触れました。これについては、AppDevelopers が犯したデータベース開発の過ち(例: 排他的なアーク)で詳しく書きました。

あなたの問題に関しては、私は実際にはこれらのオプションをどれも選択しません。あなたがつまずいているのは、一般的な Party モデルです。基本的に、Person や Organization などのサブタイプを持つ Party エンティティがあります。Contacts には外部キーとして Party ID があります。共通のスーパークラス/スーパーエンティティの使用は、それよりもはるかに深遠ですが、これを他の多くのものにも使用することがわかります (たとえば、ロールの概念全体)。

これらのデータベース設計モデリングの問題の多くには、成熟した解決策がありますが、プログラマーが教えられるようなものではない傾向があります。本を入手することを強くお勧めします The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises。人や組織をモデル化する方法や、その他の多くの典型的な問題について、より詳細に説明しています。

ここで覚えておくべき重要な点は、あなたがしていることは以前に行われたということです。

于 2009-03-16T21:27:33.910 に答える
0

オプション＃2または私はこれを行います：

Idとエンティティタイプを定義するEntityTableを作成してから、Address、Emailテーブルをそのタイプにリンクさせることができます。

次に、エンティティを参照する個人および会社のテーブルを作成します。言い換えれば、あなたのサブクラス化エンティティ。

オプション＃1-私は過去にこれを使用しましたが、物事が複雑になり成長するにつれて、管理するのが頭痛の種になる可能性があります。

オプション＃3-参照の整合性を使用することはできません。オプション＃2を実行するためにいくつかのキーストロークを保存することで得られるコストは、不良データをクリーンアップしたり、余分な複雑さに対処したりする価値はありません。

于 2009-03-16T21:11:00.110 に答える