web-dev-qa-db-ja.com

一般的な人のフィールド（名前、メール、住所、性別など）のベストプラクティス

次のような一般的なフィールドの長さとデータ型に関する最も一般的なベストプラクティスは何ですか。

  • ファーストネーム
  • 苗字
  • 住所
  • Eメール
  • 性別
  • 状態
  • 市
  • 国
  • 電話番号

等....

database-designbest-practices
44
Snow_Mac

これらのフィールドのほとんどについて、悪魔は詳細にいるため、私は普遍的なベストプラクティスのセットを非常に疑う傾向があります。情報が比較的一般的であるという理由だけで、アプリケーションが他のアプリケーションが使用するのとまったく同じ方法でデータを使用することを意味しません。つまり、データモデルが少し異なる必要がある場合があります。

  • 姓名：なぜ名前を取得しているのですか？人の正式な氏名を取得する必要がある場合（つまり、法的文書または出生証明書を準備している場合）、人の名前を尋ねるだけの場合よりも、人が入力できるスペースを広くしたいと思うでしょう。新しいWebアプリでそれらを呼び出す何かを持っています。
  • 住所：住所をどのように扱いますか？どのような種類のアドレスを保存していますか？住宅ローンを作成している米国のプロパティの住所を保存している場合、完全に標準化された住所を取得することに非常に注意を払うことになります。この場合、データモデルはおそらくあなたの住所に非常に近づきたいでしょう。標準化ツールが戻ります。人々が製品を配達するために住所をタイプできるようにしたいだけなら、フリーフォームのテキストのための数行でおそらく十分です。そこにある行の長さは、住所ラベルの印刷などを行うダウンストリームプロセスの要件によって異なります。
  • 状態：有効な状態値を識別できると仮定すると、STATEテーブルを作成し、STATEテーブルとADDRESSテーブルの間に外部キー関係を作成することはおそらく意味があります。しかし、有効な値を識別できるということは、有効なアドレスのセットを少なくとも特定の国のセットに制限していることを意味します。多くのサイトではそれで問題ありませんが、新しい国をサポートするために少し作業を行う必要があります。
  • 市：市レベルの規制が存在する可能性のあるデータ（つまり、市に基づいて適用されるさまざまな種類の税率が存在するデータ）を扱う場合は、州と同様に扱い、 CITYテーブルと有効な都市、およびCITYテーブルとADDRESSテーブル間の外部キー関係。一方、商品を配達しようとしているだけで、同じ都市のさまざまなバージョンがテーブルにあるかどうかをあまり気にしない場合は、ユーザーが自由にテキストを入力できるようにするだけで十分です。もちろん、外部キーを格納している場合は、すべての有効な値があることを確認するためにかなりの作業が必要になります。しかし、会社がその仕事をすでに完了しているということの要点である製品（つまり、消費税データベース）があります。
  • 電話：電話番号をどのように扱っていますか。その理由は何ですか。一部のアプリケーションでは、ユーザーが入力することを決定した形式で電話番号を取り込み、それ以降のすべてのクエリでその形式を保持する必要があります。これは、ユーザーが電話番号の格納方法と表示方法を自分で設定できる個人用アドレス帳を設計する場合に一般的です。他のアプリケーションでは、入力されたフォーマットを無視し、数字のみを抽出し、検索時にデータをフォーマットして、すべての電話番号が同様のフォーマットになるようにします。企業向けの場合は、ユーザーが内線番号を入力するための別のフィールドが必要になる場合があります。アウトバウンドコールプロセスをサポートする場合は、異なる市外局番の人々に電話をかけるためのタイムゾーン固有のウィンドウがあることを確認する必要があるため、市外局番と国コードを別々の列に格納することができます（午前10時に東部標準時の誰かに電話をかけると、太平洋標準時の午前7時の人に同じ電話をかけるよりもはるかに上手く行きます。
  • 性別：非常に多くのアプリケーションで、性別コード（ 'M'または 'F'）をテーブルに格納することは完全に合理的です。一方、追加オプション（その他、インターセックス、トランスジェンダー）が必要な場合や、出生時の性別や現在の性別などを保存する必要がある場合があります。
50
Justin Cave

同様に、サンプルデータと予想されるオーディエンスに基づいて推測することもできます。それはあなたの場所に依存します。

いくつかのメモ：

住所：

名前：

電話番号：国際コード、長さ、携帯電話と自宅、携帯電話のみを番号として許可

24
gbn

上記のすばらしい答えに加えて、ユニコード文字を受け入れることを忘れないでください。米国にいるからといって、列に外国文字を受け入れたくないという意味ではありません。

そうは言っても、私は通常50文字の名前を推奨しています。 320は、電子メールアドレスとしては十分すぎるはずです（ANSI標準で確認できます）。 255文字で注意側のアドレスエラー用。それほど大きなアドレスが必要になることはおそらくないでしょうが、C/O行などを含めると、そうなる可能性があります。都市はかなり大きいはずです。かなり長い都市名がいくつかあります。国の場合、国と同じように子テーブルを使用します。郵便番号については、米国の郵便番号よりも長い国際郵便番号を忘れないでください。インターナショナルをサポートしていないからといって、まだサポートされているかもしれません。軍人を含むさまざまな郡に住んでいる米国市民がたくさんいます。

多くの国には州がないため、州はオプションであることを忘れないでください。

10
mrdenny

フェンスの上に座っているとお尻が痛くなってきたので、答えを捨てて忘却に投票しないことを望みます。建設的な批判をしてください。

電子メールアドレス：

最小：6（[email protected]）。または、ローカルドメインのメールアドレスを追跡する場合は3
最大： 320 254（RFC）

メールを検証するためのコードの量は実際には非常識なので、「@」がある場合は有効であると仮定しましょう

メールアドレスを「通信方法」として抽象化すると、ユーザーと通信するためのすべての方法を簡単に一覧表示できます。

性別

性別は時間の経過とともに変化する可能性があるため、それが重要な場合は追跡できます。フォロー http://en.wikipedia.org/wiki/ISO/IEC_5218

NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);

アドレス：NORAM

私は安い方法を取り、北米の住所に固執するつもりです。

主に課税のために、国、部門、都市、郡を抽象化するのに便利です。税金はさまざまなレベルで適用される可能性があるため、抽象的な地理的領域で税率を示すことができれば、黄金です。

GeographicArea：

id: int  
type: {country, division, county, city, indian reservation}  
name: varchar(45)  [1]
abbreviation: nullable varchar(4)  
parent_id: nullable int

住所：

id: int  
postal_area_id: int, references GeographicArea  
county_or_city_id: int, references GeographicArea  
street_address: varchar(255)  
suite: nullable varchar(255)

必要に応じて、line2およびline3を追加します。

参照 http://en.wikipedia.org/wiki/Address_（geography）

今、アドレスはアドレスです。 1人のアドレスに複数の人が住むことができ、1人の人が同時に複数のアドレスを持つことができるため、そのためには多対多のテーブルが必要です。

PartyAddress

party_id: int references Party  
address_id: int references Address  
purpose: {home, work, ...}

from_dateおよびnullable to_date長期間追跡する場合。

電話番号

パーティーは複数の電話番号を持つことができ、電話番号は複数の人が使用できます。電話番号は、ファックス、電話、モデムなどに使用でき、内線番号を持つことができます。これらも時間とともに変化する可能性があります。

PhoneNumber

id: int  
value: varchar(15) - the max allowed by the ITU

最小値は3（ "911"の場合）、またはおそらく7（ "310-4NET"、これは市外局番をダイヤルできない特別な種類の市内番号です）

必要に応じて、これを国コードなどに分割できます。

http://en.wikipedia.org/wiki/E.164 標準を使用する必要があります

PartyPhoneNumber

party_id: int references Party  
phone_number_id references PhoneNumber  
extension: nullable varchar(11) - ITU max  
purpose: {home, work, fax, modem, ...}

お名前

名前は難しいです。理由は次のとおりです。

  1. 一部の人々は、1つの単語のみが含まれる正式な名前を持っています http://en.wikipedia.org/wiki/List_of_legally_mononymous_people

  2. 一部の人々は多くの単語で名前を持っています http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior

  3. 一部の人々は同時に複数の名前を持っています（たとえば、私の大学には多くのアジア人の学生がいますが、彼らは「好ましい」より西洋化された名前を使用したいです）

  4. 場合によっては、旧姓や既婚名など、人の名前を時系列で追跡する必要があります。

  5. さまざまな理由で個人や組織を抽象化したい

    テーブルparty（id bigserial primary key）;を作成します。

    create table party_name（id bigserial primary key、party_id bigint not null references party（id）、type smallint not null references party_name_type（id）--elided、ex "maiden"、 "legal"）;

    create table name_component（id bigserial primary key、party_name_id bigint not null references party_name（id）、type smallint not null references name_component_type（id）、--elided ex "given" name text not null）;

9
Neil McGuigan

以前の回答とは少し異なる観点から、そして LDAP について話すことは問題ないように見えるため、 RFC 4519-"Lightweight Directory Access Protocol（LDAP ）：ユーザーアプリケーションのスキーマ」 が興味深いかもしれません。

アプリケーションをそのようなディレクトリにマッピングする必要がある場合に役立ちます。それ以外の場合は、おそらく要件に適合していません。

これらの定義は単なるデータに関するものではなく、フィールドで使用できるいくつかの演算子に関するものでもあります。 postalAddress たとえば、 caseIgnoreListSubstringsMatch です。このスキーマに厳密に従うことをお勧めしませんが、原則を確認することは興味深い場合があります。特に、アプリケーションの名前とアドレスを比較する方法がデータベースの設計に関連している場合があります。

3
Bruno

名前については、二重引用符を使用することを検討してください。これにより、アイルランド語またはイタリア語の名前（例：O'HaraまたはD'Amato）のアポストロフィをエスケープする必要がなくなります。

名前フィールドの一部を出力できるように、適切な正規表現のセットを取得することもお勧めします（たとえば、最初のイニシャル、ニックネーム、Jr/Srなど）。

3
KiloVoltaire