在常见字段上，有关长度和数据类型的最常见最佳做法是：
- 名字
- 姓
- 地址
- 电子邮件
- 性别
- 州
- 市
- 国家
- 电话号码
等等....
这个问题很广泛。应该清除并删除它。
—
埃文·卡罗尔
在常见字段上，有关长度和数据类型的最常见最佳做法是：
等等....
Answers:
对于任何通用的最佳实践，我都会非常怀疑，因为在大多数这些领域中，细节在于魔鬼。仅仅因为信息相对普遍并不意味着您的应用程序使用数据的方式与其他应用程序使用数据的方式完全相同。这意味着您的数据模型可能需要稍有不同。
STATE表并在STATE和ADDRESS表之间创建外键关系可能很有意义。但是识别有效值的能力意味着您将有效地址集至少限制在特定的国家/地区中。对许多站点来说都很好，但是您需要做一些工作来支持一个新国家。CITY带有有效城市的表格CITY以及和ADDRESS表格之间的外键关系。另一方面，如果您只是想交付产品，并且您不太在意表中是否有同一个城市的各种版本，那么让用户自由输入文本就足够了。当然，如果要存储外键，则需要进行大量工作以确保拥有所有有效值。但是有些产品的重点是公司已经完成了这项工作（即营业税数据库）。您还可以根据样本数据和预期的受众进行猜测。这取决于您的位置。
一些注意事项：
地址：
名称：
电话号码：国际代码，长度，手机号码与房屋号码，允许手机作为唯一号码
除了上述出色的答案外，别忘了接受unicode字符。仅仅因为您在美国并不意味着您不想在列中接受外来字符。
也就是说，我通常建议使用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);
我要走便宜的路，坚持北美洲的地址。
主要由于税收，可以方便地提取国家，地区，城市和县。税收可以适用于多个级别，因此，如果您可以将税率指向抽象的地理区域，那您就很聪明。
地理区域：
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)
添加第2行和第3行（如果需要）。
参见http://en.wikipedia.org/wiki/地址（地理）
现在，地址就是地址。一个人可以住一个地址，一个人可以同时有多个地址，并且随着时间的流逝，因此您需要一个多表。
派对地址
party_id: int references Party
address_id: int references Address
purpose: {home, work, ...}
如果随时间推移进行跟踪，请添加from_date和可为空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标准
派对电话号码
party_id: int references Party
phone_number_id references PhoneNumber
extension: nullable varchar(11) - ITU max
purpose: {home, work, fax, modem, ...}
名字很难。原因如下：
有些人的法定姓氏只有一个字http://en.wikipedia.org/wiki/List_of_legally_mononymous_people
某些人的名字中包含许多单词http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
有些人同时拥有多个名字（例如，在我的大学里有很多亚洲学生，但他们喜欢使用“首选的”更西化的名字）
有时，您需要随着时间的推移跟踪人们的姓名，例如婚前姓氏和已婚姓氏。
您出于各种充分的理由想要抽象个人和组织
创建表方（id bigserial主键）；
创建表party_name（id bigserial主键，party_id bigint不是null引用party（id），类型smallint不是null引用party_name_type（id）-已消除，例如“ maiden”，“ legal”）；
创建表name_component（id bigserial主键，party_name_id bigint不是null引用party_name（id），键入smallint不是null引用name_component_type（id），-省略ex“给定”名称文本，不null）；
从与以前的答案稍有不同的角度来看，并且既然可以谈论LDAP似乎是可以的，那么RFC 4519-“轻型目录访问协议（LDAP）：用户应用程序的架构”可能会引起人们的兴趣。
如果您的应用程序需要映射到这样的目录，则可能会很有用。否则，它可能不适合您的要求。
这些定义不仅涉及数据，还涉及可在字段上使用的一些运算符。postalAddress，例如caseIgnoreListSubstringsMatch。我并不是建议您严格遵循此架构，但是查看原则可能会很有趣，特别是您可能必须比较应用程序中的名称和地址可能与数据库的设计有关。