私は、ビジネスアプリケーションのデータベースに個人の連絡先を保存するための最良の方法を考えています。従来の簡単なアプローチは、各要素、つまり名前、電話番号、役職、住所などの列を持つテーブルを作成することです。ただし、この種のデータには、vCardなどの既知の業界標準があります。またはhCard、またはvCard-RDF / XML、さらにはWindows連絡先XMLスキーマ。標準フォーマットを利用すると、他のシステムとの相互運用性など、いくつかの利点があります。しかし、どの方法を使用するかをどのように決定できますか？
要件は主にデータを保存することです。検索と順序付けのクエリはほとんどありませんが、可能です。データ量は最大100,000レコードです。
私のデータベースエンジンはネイティブXML列をサポートしています。個人の連絡先を保存するために、XMLベースの形式を使用することを考えていました。そうすれば、検索と順序付けが必要な場合に、このデータでXMLインデックスを利用できるようになります。これは良いアプローチですか？このためにどの連絡先フォーマットとスキーマをお勧めしますか？
最初の回答後に編集
これが、単純なアプローチが悪いと思う理由です。これは、この種のデータの性質によるものです。それほど単純ではありません。
- 個人的な連絡先は、適切に構造化されたデータではなく、半構造化と呼ばれる場合があります。連絡先ごとに異なるデータフィールドがある場合があります。おそらく、私が予測できないようなフィールドでさえあります。私の意見では、このデータの各部分は重要な情報として扱われる必要があります。つまり、データベースに関連する列がなかったという理由だけでデータを破棄することはできません。
- さらに進んだ場合、データが失われる可能性がないと仮定して、Comment、Description、またはOtherという名前の大きなテキスト列を作成し、テーブルの列にうまく収まらないものをすべてそこに置くことができます。しかし、再び-データは構造を失うでしょう-これは悪いかもしれません。
- 構造化データが必要な場合は、データベース設計の原則に従って、データをエンティティに分解し、エンティティ間に関係を確立する必要があります。しかし、これは複雑さを増します。エンティティが多すぎるため、「住所、個人名、電話番号、自宅の電話番号と携帯電話番号をどのようにエンコードするか、その他はどうすればよいか」など、多くの設計設計を行う必要があります。連絡先情報？.. "エンティティ間の関係は複雑で複数であり、各関係はデータベース内のテーブルです。各関係は、設計ペーパーに文書化する必要があります。それはやるべきことがたくさんあります。しかし、複雑さを完全に回避することは可能です-データがそのようなものに従って保存されていることを文書化するだけです標準スキーマ、期間。そうすれば、そのドキュメントを読んでいる人なら誰でも、それが何であるかを簡単に理解できるはずです。
- 最後に、これはすべて業界標準の使用に関するものです。この標準は、個人の連絡先情報の構造を私がこれまでにないほどうまく予測して説明した賢い人々によって設計されていることを願っています。なぜ私たちは皆、車輪の再発明をしなければならないのですか？標準スキーマを使用する方がはるかに簡単です。問題は、標準が多すぎることです。どれを使用するかを決めるのは簡単ではありません。