0

私は現在、多くのエンティティ（人、組織）と多くの連絡先情報を持つWebビジネスアプリケーションに取り組んでいます。複数の住所、メールアドレス、電話番号など

現時点では、データベース スキーマは、個人テーブルに郵便番号列、組織テーブルと同様に電話番号列があるようなものです。これは、これを処理する良い方法ではありません。

私はこれについて c2 Wiki を読みましたが、連絡先と住所のモデル ( http://c2.com/cgi-bin/wiki?ContactAndAddressModels ) と物理アドレスが古風であるかどうか ( http://c2 .com/cgi-bin/wiki?ArePhysicalPostalAddressesArchaic )。これらの 2 つの議論は、この問題の範囲について本当に私の目を開かせてくれました。

連絡先情報フィールドを分離してテーブルを分離することを考えています。しかし、これを行う最善の方法は何ですか。現時点では、このアプリケーションは主にフィンランドの住所を処理しますが、国際的な住所も処理する必要があると考えられています。

「住所」テーブル、「電話番号」テーブル、「電子メール アドレス」テーブルなどを定義でき、これらは人や組織にリンクされます。しかし、これは前のソリューションに似すぎているように感じます。定義済みのデータベース スキーマが十分でないことは避けられません。

私が提案しているのは、動的な連絡先情報スキーマ/プログラム ロジックを作成することです。

  • 事前定義された連絡先情報フィールド/フィールド セットはありません
  • ユーザーはいつでも新しい連絡先情報の種類と必須フィールドを定義できます。
    • フィンランドの住所
    • スウェーデンの住所
    • ... 住所
    • 電話番号
    • 電子メールアドレス
    • ICQ番号

これは実現可能ですか？誰かがこのようなことをしましたか？

連絡先情報の種類を定義するテーブルが存在する可能性があります。

連絡先情報の種類

  • Id: 識別子
  • 名前: 「フィンランドの住所」
  • 説明: 「フィンランドの住所にはこの連絡先情報タイプを使用してください」


次に、連絡先情報の種類ごとに使用されるフィールドを定義するテーブルが存在する可能性があります。

連絡先情報タイプ フィールド

  • Id: 識別子
  • Contact_information_type_id: 前の表を参照
  • フィールドのタイトル: 「住所 1」
  • フィールドの説明: 「この行を郵便住所の最初の行に使用する」
  • フィールド タイプ: 文字列/整数/など。
  • フィールド形式: フィールド データを検証するための正規表現
  • フィールドの順序: この連絡先情報の種類を表示/使用するときに、このフィールドが表示される順序


次に、連絡先情報フィールドを一緒にマップするために使用される「連絡先情報テーブル」を作成します。

連絡先

  • Id: 識別子
  • Contact_information_type_id: 連絡先情報種別テーブルを参照


次に、さまざまな連絡先情報を人にマッピングする「連絡先情報」テーブルを作成します。

本人連絡先

  • Id: 識別子
  • Contact_information_id: 連絡先情報テーブルを参照します
  • 個人ID：個人を参照します


次に、次のような連絡先情報フィールド タイプごとのテーブルが必要になります。

連絡先情報整数フィールド

  • Id: 識別子
  • Contact_information_id: 連絡先情報テーブルを参照します
  • 値: このフィールドの値

    • などの文字列など...

    最後に、特定の人物のさまざまな連絡先情報を表示する場合、これはその人の連絡先情報テーブルを通じて発生します。この連絡先情報を形成するために使用されるフィールドは、連絡先情報タイプ フィールドテーブルから連絡先情報テーブルを通じて検索されます。使用するフィールドを決定したら、必要なすべてのテーブルを結合します。

    SQLでの実現可能性について疑問があります。何かご意見は？

    Java では、おそらく何らかのロジックをプログラムして、連絡先情報エンティティを形成するために必要なテーブルを決定し、何らかの動的 Bean を使用して Java でこのデータを表すことができます。しかし、それは私にとっても少し曇っています。これについても考えていますか？

    4

    4 に答える 4

    1

    完全に優れたハンマー（つまりSQLデータベース）があり、それを使って別のハンマー（SQLスキーマを定義するためのメタ言語）を作成しようとしているように聞こえ始めています。

    この道を進む前に、SQLデータベースに顧客の詳細を保存することを目的とした多くの製品が市場に出回っています。既製のものを購入して統合するのが最善かもしれません。次に、あなたが持っているすべての懸念は他の誰かによって対処され、あなたはあなたの特定のビジネスケースに集中することができます。

    編集：カスタム連絡先フィールドを追加できるパッケージの1つの例は、SugarCRMです。これは、購入時にソースへのアクセスを購入する商用製品です。もっとたくさんあると思いますが、現時点で頭に浮かぶのはこれだけです。

    于 2008-09-17T07:52:22.967 に答える
    1

    あなたのデザインは実現可能であり、私は次の人と同じくらい正規化のファンですが、あなたは本当にどこかでバランスを見つける必要があります。ですから、最初に、address1、address2、address3などのフィールドを持つことは悪い習慣だと思います。また、さまざまな国のさまざまな種類の郵送先住所を処理することを計画している場合は、さまざまな種類の住所を抽象化することが理にかなっている場合があります。

    システムから取得したいデータについて考えてみてください。たとえば、誰かが特定の州または州のすべての顧客を求めているのでしょうか。その場合、あなたのデザインはかなり苦痛になります。

    もう1つ覚えておくべきことは、データベーススキーマの変更は、時には苦痛を伴うこともありますが、世界で最悪のことではないということです。そのパスを論理的に極端にたどると、「key」や「value」などのフィールドと、すべてのクエリに数千の自己結合を持つ1つの巨大なテーブルができあがります。

    適切なバランスを見つけて頑張ってください！

    于 2008-09-17T07:56:45.123 に答える
    0

    まず、実用的に言えば、データをどのように処理するかによって異なります。私の経験では、すべての住所データの99％は、手紙に印刷される文字列としてのみ使用されています。その場合は、心配するのをやめて、文字列として保存する必要があります。もちろん、あなたがそれを使ってより深い仕事をしているなら、それはそれほど簡単ではないでしょう。

    それとは別に...私はあなたの考え方が好きです。動的スキーマを処理するために、（アドレスではありませんが）同様のことを行いました。私が遭遇した問題は、（あなたが特定したように）ものを抽出するためのSQLが複雑になることです。もう1つの問題は、この柔軟性がスパゲッティコードを取得するのとまったく同じ方法で、スパゲッティデータにつながる可能性があることです。つまり、テーブルにアクセスするコードを見るだけで理解できるため、テーブルの内容の意味がわかりにくくなる可能性があります。

    したがって、決定する必要があるのは、複雑さを受け入れる準備ができている場所と、どのような種類の複雑さを最も適切に処理できるかです。複雑なSQLを気にしない場合は、先に進んで動的スキーマを構築してください。複雑なSQLを気にする場合は、静的テーブル（アドレスタイプごとに1つのテーブル）を作成するか、このような洗練されたデータ構造がないことを受け入れてください。

    だから、簡単な答え：あなたはそれを呼び出さなければなりません。

    于 2008-09-17T08:57:00.220 に答える
    0

    これはあまり有益な投稿ではありません。vCardの人々が同じ問題をどのように処理するかを見たことがありますか？また、過剰設計に注意してください。N3になる可能性があります。

    于 2008-09-17T07:50:43.313 に答える