顧客情報レコードの事実上の標準[終了]

現在、一般的な顧客情報（ユーザーID、パスワード、姓、名、電子メール、住所、telfnrなど）のデータベースを作成する新しいプロジェクトの可能性を評価しています。この時点で、要件は大まかにのみ定義されています。

顧客DBは、何百万ものレコードに含まれていると予想されます。DBサイジングのためのいくつかの裏側の数値を計算し、潜在的なDBオプションとアーキテクチャを評価するために、これらの種類のレコードの事実上の標準を探しています。特に、すべてのフィールド（名、姓、住所など）の標準サイズ、または単純な顧客レコードの一般的な平均は素晴らしい情報です。

非常に多くのeコマースWebサイトがあるため、再利用でき、車輪の再発明を避けることができる、ある種の典型的な構成が必要です。

何か案は？

----編集----

答えは、標準の顧客レコードを採用するのではなく、独自のレコードを設計することに向かっているようです。この質問の焦点は、顧客オブジェクトのフィールドサイズの参照を見つけることであり、それを自分で理解することを避けることであることを強調したいと思います（元のテキストの部分を強調しました- 今は太字にしています）。

標準の良いところは、選択できるものが非常に多いことです。- アンドリュー・スチュアート・タネンバウム

このようなことは顧客と業界に非常に固有のものであり、一般的なものにはすべてとキッチンシンクが含まれます。特にEDIタイプのフォーマットは、ほとんどの場合10年以上にわたって有機的に定義され、委員会のすべての企業がこれまで望んでいたすべてのものが含まれます。それらは業界のジェネリックであると想定されていたため、非常に業界固有で非常に脆弱になりました。

あなたが望むデザインや情報への王道はありません。時間と労力をかけて要件を取得し、具体的な見積もりを取得します。そうでなければ、あなたは正しいというよりも間違っているでしょう。知っておくべきことを知る唯一の方法は、質問をして自分でそれを理解することです。

多くのCRMシステムは、以前は動的プロパティパターンと呼ばれていた、今ではExpandoオブジェクトパターンと呼ばれるものを使用します。基本的には、キーと値のペアの辞書構造です。非常に特別な場合を除いて、それはデザインのアンチパターンと見なされ、避けるべきです。

過去20年間で少なくとも8つのカスタムCRMソリューションを設計および構築しましたが、それぞれが要件が異なり、すべてのドメインでデータモデル（論理または物理）が全面的に機能しませんでした。

特定のケースに対する特定のソリューションは、常に優れた設計になります。

DBAスタックには、問題を議論する一般人の分野のベストプラクティスに関するスレッドがあります。データをどのように処理するか、どの程度徹底する必要があるかは非常に重要です。実際にすべての有効な電子メールアドレスまたはすべての有効な名前をサポートする必要がある場合、列は、組織およびアプリケーションが有効な値の合理的なサブセットと見なすものを単にサポートする場合よりもはるかに大きくする必要があります。

Jarrodが指摘したように、一般的な標準に従えば、間違いなく、システムに必要のない多くのものを含むレコード形式になります。かなり多数のレコードが存在することを既に知っているため、使用されないデータをサポートしているため、不必要なパフォーマンスの問題が発生する可能性があります。逆に、標準には必要なフィールドが含まれていない可能性も高く、これは解決が困難な問題です。これらのフィールドを追加して標準を破るか、非標準フィールドを標準内に含める何らかの（おそらく不格好な）方法を見つける必要があります。

ここでの本当の問題は、万能サイズの標準（ほとんどの場合万能サイズになります）を見つけることではなく、要件が満たされていないソリューションを見積もることが課題だと思いますまだ指定されています。これらの場合、私がやるべき唯一の専門的なことは、あなたが持っている要件に基づいて最小の見積もりを行い、次にあなたが思い付く可能性があるすべての未定義の要件に基づいて最大の見積もりを行うことだと思います。案の定、推定はとてつもなく荒くなる可能性があります。その場合は、これを担当した人に説明する必要があります。要件がより明確になるまで、適切な推定を行うのは現実的ではありません。

既存の国際規格

かなりの数の標準がありますが、特定のフィールドに固有であり、データ収集のニーズに応じてそれぞれの要件が異なります。

たとえば、これらに限定されない（およびこれらの両方の経験から話す）：

• 特定の仕様の認定を受ける予定の場合、患者データと医療記録を処理するソフトウェア。
  • ポイントオブケアで患者の医療記録情報を取得するための統一データ標準（医療記録のさまざまな標準のリストを提示）
• Eletronic Medical Recordsとその技術基準

• 電子健康記録とその技術基準の幅広い分野

• モバイルオペレーターの通話データレコードとサービスデータレコードを処理するソフトウェア（標準としてではなく、パートナーネットワーク間の相互運用性のため）。

上記の一部は、かなり詳細なドキュメントにリンクしており、健全性とフィールドのフォーマットの要件さえリストしています（たとえば、HL7は明確に定義された データ型を使用します）。しかし、多くの場合、これほど詳細には行きません。

内部記録に関する政府主導の基準

国や地方の政府は、多くの場合、公的機関の個人情報を記録および保存する必要性が高く、明らかに組織内で実装する独自の「標準」を策定しています（さまざまなレベルの成功とパートナー組織との相互運用性を備えています） 。

例は、ニュージーランド政府のアイデンティティレコード標準のこのデータ形式です。

ソフトウェアのデファクトスタンダード

これらからインスピレーションを得るか、既知のオープンソースCRMソフトウェアのソースを使用して、顧客データのデータ仕様のベストプラクティスおよびガイドラインとして使用できます。

参照してくださいトップ10のオープンソースビジネスとソーシャルCRMソフトウェアのリストを、あなた自身が自分のデータ・モデルを調べることができたため。

EDIシステムの標準を見つける必要があると思います。何百もの「標準」ドキュメントがあるため、要件に基づいてドキュメントを選択する必要があります。たとえば、次のTRADACOMS請求書の形式は、必要なフィールドを取得できます。

開いているアプリケーショングループは、アプリケーションの実装との相互運用性のためのオープンな標準のセットを発行しています。それらはほとんどがXML指向ですが、個々のフィールドとサイズを使用して標準の顧客レコードを指定します（CustomerPartyMasterドキュメント標準リストを参照してください）。

私は「あなたはそれを必要としない（まだ）」と言うでしょう。また、Ron Jeffries氏は次のように述べています。

そのため、プロジェクトに具体的なデータベースを追加するときが来たら、そこに保存されるデータについてより多くの知識を持っているでしょう。