2

アップグレードが必要な古いアプリケーションがあります。すべてが今ではありませんか？

既存の DB スキーマは、電話、ファックス、電子メールなどの定義済みフィールドで構成されています。過去 5 ～ 7 年間 (または国によってはそれ以上) の社会的爆発により、エンド ユーザーは、私が便利だと思うものだけでなく、自分に合った方法で連絡先カードを作成することをより詳細に制御する必要があります。

私はここで「デジタル」アドレスに関心があります。つまり、1 行タイプの住所です。phone=ccc ccc ccc ccc など この場合、物理アドレスは要件の点で非常に標準的であるため、ユーザーは範囲を管理しやすくするために、指定されたもの (場所、郵便番号、配送先) を使用する必要があります。

だから、デジタル情報を保存するためのベストプラクティスのフォーマットは何だろうと思っています。私には2つの選択肢があるようです：

  1. シンプルな 4 フィールド テーブル (ContactId、AddressTypeId、Address、FormatterId)

1000、「電話」、「ccc ccc ccc ccc」、phoneformatter

1000、「facebook」、「myfacebook」、facebookformatter

これは、必要な場所で結合されます。ただし、テーブルは巨大になり、時間の経過とともに結合のパフォーマンスが低下すると思われます。

  1. 読み取り後に追加の処理が必要な json blob (ContactId、Addresses)

1000、{{"電話": "ccc ccc ccc ccc"}、{"facebook": "myfacebook"}}

または、他の何か。

このデータベースは、顧客ベースが 3000 ～ 12000 のアカウントの範囲で国内取引のみを行っている特定の国で使用するためのものであり、アカウントごとの連絡先の数 (現在のシステムでは平均約 10) に制限されています。

私の主な関心事はユーザーの柔軟性ですが、パフォーマンスはその中で重要な考慮事項です。だから私は知りません、ただ何でもして、それにたくさんのハードウェアを投げてください;）

クエリ後処理に関して違いがある場合、アプリケーションはC＃にあります。

4

2 に答える 2

1

私は JSON ブロブには行きません。次のようなクエリに答える必要がある場合、これは厄介です。

  • Facebookの連絡先に私を知っている人はいますか?
  • 最も人気のあるソーシャル メディアの連絡先の種類は何ですか?

すべてのレコードに対して JSON を解析する必要があり、単純なインデックスを作成することはできません。

あなたの追加の解決策はほぼ正しいですが、 FormatterId は AddressType テーブルにある必要があります。FormatterId は AddressTypeId のみに依存するため、正規化されていません。したがって、次の 3 つのテーブルがあります。

  • コンタクト
  • 連絡先住所
  • 住所タイプ

1 つの連絡先に対して同じタイプの 2 つのアドレスを保存する必要があるかどうかは述べていません。たとえば、誰かが 2 つの Twitter アカウントを持っているとします。この質問に答えると、ContactAddress に正しい主キーを定義できます。連絡先ごとに各タイプを 1 つしか持てない場合は (ContactId, AddressTypeId) にするか、合成キー (ContactAddressId) を作成します。

于 2013-06-19T06:10:52.073 に答える
0

contact という名前のテーブルがあると思います。

contact(contactid, contact details, other details)

連絡先の詳細にはデジタル アドレス、電話番号、その他すべてが含まれている可能性があるため、この連絡先の詳細を連絡先テーブルから削除する必要があります。

しかし、あなたが検討しているテーブル

(ContactId, AddressTypeId, Address, FormatterId)は通常の形式ではなく、4 つの列をすべて読み取るまでタプルを一意に識別できません。これは悪いことであり、この場合、インデックス作成も役に立ちません。

デジタルアドレスのタイプごとに別々のテーブルがあり、contactIDにインデックスがある場合は、より良い

facebookdetails(contactid, rest of the details)
phonedetails(contactid, rest of the details)

そして、クエリはすべてのテーブルを結合できますが、パフォーマンスが低下することはありません。

これが役立つことを願っています:)

于 2013-06-19T05:38:38.410 に答える