3

私はこれまでに書いたすべてのアプリケーションでこの問題を乗り越えてきました。最終的なコンセンサスの答えが欲しいです！

これは、連絡方法やその他のデータをこのパターンに沿ってデータベースに保存するための最も正規化された/効率的な/適切な方法ですか？

Contact { PK ContactId, ... }

ContactContactMethod {PK FK ContactId, PK FK ContactMethodId, Key, Comments }

AddressContactMethod {PK FK ContactMethodId, Line1, Line2, City, State, Zip }
EmailContactMethod {PK FK ContactMethodId, EmailAddress }
InstantMessengerContactMethod {PK FK ContactMethodId, IMClient, IMAddress }
PhoneContactMethod {PK FK ContactMethodId, ... }
WebsiteContactMethod {PK FK ContactMethodId, ... }
OtherContactMethod {PK FK ContactMethodId, ... }

代わりに、テーブルContactMethodData上のXmlフィールドを検討する必要がありますか？ContactContactMethod

AddressContactMethod、EmailContactMethodなどがすべて主キーの同じ一意性を共有していることについて何かがおかしいと感じています。

連絡先データのキーと値のペアについても考えましたが、それはXmlフィールドよりもクエリを実行するのがさらに面倒です。

（設計ガイドライン：各連絡先には、各タイプの連絡方法が複数ある場合とまったくない場合があり、それぞれに「自宅、職場、赤い車など」などの一意でない「キー」とコメントがありますが、タイプ間で他の共有データ要素はありません）。

4

5 に答える 5

2

このパターンには名前があります。それは「専門化一般化」と呼ばれます。

この場合、連絡方法は、連絡先に連絡するための特殊な方法です。

「汎化特化リレーショナル デザイン」で Web 検索すると、このパターンをより一般的な方法で扱っている記事がいくつか見つかります。同じパターンのオブジェクト指向のビューについては、「一般化特化オブジェクト設計」で検索してください。

于 2009-03-11T05:25:16.060 に答える
2

あなたと同じように、私は連絡先情報データベースの設計について、私のシェア以上のものを見てきました。私はあなたのものはかなり合理的だと思います.*メソッドテーブルとは別にキー列を配置することはいい感じです.「自宅」の電子メールと郵便アドレスのグループ化をファッションの後にグループ化することができます.

ただし、ほとんどの連絡先データベースは過剰設計されていると思います。Chris Lively のアプローチには同意しませんが、連絡先情報の種類 (電子メール、電話、Web URL など) を用意し、それぞれに単純なテキスト文字列を格納するだけで簡単にできると思います。個別のタイプを検証しようとしたり、それらをサブフィールドに分割しようとしたりすることは、通常、努力する価値はありません。1 つには、米国外の連絡先を許可すると、すべての電話番号と住所の検証ルールがすぐに適用されなくなります。完全なアドレスを Unicode 文字列に保存してください。最善を尽くすことをお勧めします。

これにより、次のようなデザインが残ります。

Contact { PK ContactId, ... }
ContactType { PK ContactTypeId, ContactType }
ContactMethod {PK FK ContactId, PK FK ContactTypeId, PK Key, Value, Comments }

ContactMethod.Value はテキスト値です。

これは、少なくとも Google が連絡先を追跡する方法と似ているようです。そして、少なくとも、彼らは地球上のあらゆる国からの無数の連絡先を追跡するという問題を考え抜いた可能性があります.

于 2009-03-11T03:27:27.280 に答える
1

昔は、次のようなテーブル スキーマを使用していました。

Person [ID, Name]
ContactPoint [ID, PersonID, ContactMethod]
EmailContactPoint [ID, EmailAddress]
AddressContactPoint [ID, Line1, Line2, blah]

異なるコンタクト ポイントと ContactPoint テーブルの間の 1 対 1 の関係 - 一種の継承。Hibernate/NHibernate や Entity Framework などの ORM は、これらの 1 対 1 の関係に基づいて正しい型をインスタンス化できます。

最近では、特定のタイプ (たとえば、"GetPrimaryPhoneNumber(personID)") の既定/主要な連絡先を簡単に処理できるように、XML ブロブと SQL のいくつかの関数を使用するだけです。

于 2009-03-11T03:22:48.710 に答える
1

最終的なコンセンサスの答えは、すべての人自身の答えが最善であり、他の人の答えは 1 セントの価値もないということです。それが問題です。すべての人のニーズに合う単一の方法はありません。したがって、おそらく最終的なコンセンサスの回答はありません。コンセンサスの回答でさえないかもしれませんが、最終的な回答ではないことはほぼ確実です。

于 2009-03-11T03:23:55.570 に答える