次のような一般的なフィールドの長さとデータ型に関する最も一般的なベストプラクティスは何ですか？
- ファーストネーム
- 苗字
- 住所
- Eメール
- 性別
- 状態
- シティ
- 国
- 電話番号
等....
この質問は大まかなものです。削除して削除する必要があります。
—
エヴァンキャロル
次のような一般的なフィールドの長さとデータ型に関する最も一般的なベストプラクティスは何ですか？
等....
回答:
これらの分野のほとんどについて、悪魔は細部に潜んでいるので、普遍的なベストプラクティスのセットを非常に疑う傾向があります。情報が比較的一般的だからといって、アプリケーションが他のアプリケーションが使用するのとまったく同じ方法でデータを使用することを意味するわけではありません。つまり、データモデルは若干異なる必要がある場合があります。
STATEテーブルを作成し、テーブルSTATEとADDRESSテーブルの間に外部キー関係を作成するのが理にかなっています。ただし、有効な値を特定できるということは、有効な住所のセットを少なくとも特定の国のセットに限定していることを意味します。多くのサイトではこれで問題ありませんが、新しい国をサポートするために少し手間をかける必要があります。CITY有効な都市と、テーブルCITYとADDRESSテーブル間の外部キー関係を含むテーブル。一方、製品を届けようとしているだけで、同じ都市のさまざまなバージョンがテーブルにあるかどうかをあまり気にしない場合は、ユーザーに自由形式のテキストを入力させるだけで十分です。もちろん、外部キーを保存している場合、すべての有効な値があることを確認するためにかなりの作業が必要になります。しかし、全体のポイントが会社がすでにその仕事をしたということである製品があります（すなわち、売上税データベース）。サンプルデータと予想される視聴者に基づいて推測することもできます。それはあなたの場所に依存します。
いくつかのメモ：
住所：
名前：
電話番号：国際コード、長さ、携帯電話対自宅、携帯電話のみを許可
上記のすばらしい答えに加えて、ユニコード文字を受け入れることを忘れないでください。米国にいるからといって、列に外国の文字を入れたくないという意味ではありません。
そうは言っても、通常は名前に50文字を使用することをお勧めします。320は電子メールアドレスには十分すぎるはずです（ANSI標準を確認して確認できます）。注意事項の255文字のアドレスエラーの場合。おそらくそれほど大きなアドレスを必要とすることはないでしょうが、C / O行などを含めるとよいでしょう。都市はかなり大きくなければなりません。かなり長い都市名がそこにあります。状態については、国と同じ子テーブルを使用します。郵便番号については、米国の郵便番号より長い国際郵便番号を忘れないでください。インターナショナルをサポートしていないからといって、まだそうかもしれない。軍人を含むさまざまな郡に住んでいる多くの米国市民がいます。
多くの国には州がないため、州はオプションであることを忘れないでください。
フェンスの上に座っていることでお尻が痛くなっているので、いくつかの答えを捨てて、忘却に落とされないようにしたいと思っています。建設的な批判を提供してください。
最小：6（a@g.cn）。または、ローカルドメインの電子メールアドレスを追跡する場合は3
最大：320 254（RFC）
電子メールを検証するためのコードの量は実際には正気ではないので、「@」がある場合に有効であると仮定しましょう。
電子メールアドレスを「通信方法」として抽象化し、ユーザーと通信するためのすべての方法を簡単にリストすることができます。
性別は時間とともに変化する可能性があるため、重要な場合はそれを追跡できます。http://en.wikipedia.org/wiki/ISO/IEC_5218に従ってください
NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);
私は安い方法を取り、北米の住所に固執するつもりです。
主に課税のため、国、部門、都市、および郡を抽象化すると便利です。税金はさまざまなレベルで適用されるため、抽象的な地理的領域で税率を指定できる場合は、最高です。
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_datenull を追加しto_dateます。
パーティは複数の電話番号を持つことができ、電話番号は複数の人が使用できます。電話番号は、ファックス、電話、モデムなどに使用でき、内線番号を付けることができます。これらもすべて時間の経過とともに変化する可能性があります。
電話番号
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つの単語のみを含む正式な名前を持っていますhttp://en.wikipedia.org/wiki/List_of_legally_mononymous_people
一部の人々は多くの言葉で名前を持っていますhttp://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
一部の人々は同時に複数の名前を持っています（例えば、私の大学では多くのアジアの学生がいますが、彼らは「好みの」西洋化された名前を使いたいです）
時々、旧姓や既婚者の名前など、人々の名前を経時的に追跡する必要があります。
さまざまな理由で個人や組織を抽象化したい
create table party（id bigserial primary key）;
作成テーブルparty_name（id bigserial主キー、party_id bigint not nullリファレンスparty（id）、type smallint not nullリファレンスparty_name_type（id）--elided、ex "maiden"、 "legal"）;
create name name_component（id bigserial primary key、party_name_id bigint not null references party_name（id）、type smallint not null null not name name_component_type（id）、--elided ex "given" name text not null）;
以前の回答とは少し異なる観点から、およびLDAPについて話すことは問題ないように思われるので、RFC 4519-"Lightweight Directory Access Protocol（LDAP）：Schema for User Applications"が興味深いかもしれません。
アプリケーションをそのようなディレクトリにマップする必要がある場合に便利です。それ以外の場合は、おそらく要件に適合していません。
これらの定義はデータに関するだけでなく、フィールドで使用できるいくつかの演算子に関するものでもあります。postalAddress、たとえば、caseIgnoreListSubstringsMatchです。このスキーマに厳密に従うことをお勧めするわけではありませんが、原則を見ることは興味深いかもしれません。特に、アプリケーションで名前と住所を比較する方法は、データベースの設計に関連する可能性があります。