数据库设计 – 普通人字段的最佳做法(姓名,电子邮件,地址,性别等……)[已结束]

有关常见字段的长度和数据类型的最常见最佳做法是什么,例如：

>名字
>姓氏
>地址
>电子邮件
>性
>国家
>城市
>国家
>电话号码

等等….

解决方法

我倾向于对任何一套普遍的最佳实践都非常怀疑,因为对于大多数这些领域,魔鬼都在细节中.仅仅因为信息相对常见并不意味着您的应用程序使用的数据与其他应用程序使用的方式完全相同.这意味着您的数据模型可能需要略有不同.

>第一&姓氏：你为什么要抓名字？如果您需要获取一个人的完整法定名称(即您正在准备法律文件或出生证明),您可能希望为人们提供更多的空间来打字,而不是您只是要求一个人的名字,所以你有一些东西可以在你的新网络应用中调用它们.>地址：你打算怎么处理这个地址？你要存储什么样的地址？如果您要在美国存储您正在创建抵押贷款的房产地址,您可能非常关心获得完全标准化的地址,在这种情况下,数据模型可能会非常密切地关注您的地址标准化工具返回.如果您只是希望人们能够输入地址来交付产品,那么自由形式文本的几行就足够了.线的长度可能取决于执行打印地址标签之类的下游进程的要求.>状态：假设您可以识别有效状态值,则创建STATE表并在STATE和ADDRESS表之间创建外键关系可能是有意义的.但是,识别有效值的能力意味着您至少将有效地址集限制在特定的一组国家/地区.这对很多网站都很好,但是你必须做一些工作来支持一个新的国家.>城市：如果您正在处理可能存在城市级法规的数据(即根据城市应用不同种类的税率),您可能希望将其视为与州相同的包含有效城市的CITY表以及CITY和ADDRESS表之间的外键关系.另一方面,如果您只是尝试交付产品,并且如果您的表中有相同城市的各种版本,则不必太在意,让用户自由格式输入文本就足够了.当然,如果您要存储外键,则需要进行大量工作以确保拥有所有有效值.但有些产品的重点是公司已经完成了这项工作(即销售税数据库).>电话：你在做什么电话号码,为什么？某些应用程序希望以用户决定输入的格式接收电话号码,并为所有后续查询保留该格式.如果您正在设计个人通讯录,用户可以根据自己的喜好来存储和显示电话号码,那么这种情况就很常见.其他应用程序要忽略输入的格式,仅提取数字字符,然后格式化检索数据,以便所有电话号码具有相似的格式.如果您正在为企业提供服务,您可能需要一个单独的字段供用户输入扩展名.如果您尝试支持出站呼叫过程,您可能希望将区号和国家/地区代码存储在不同的列中,因为您需要确保具有特定于时区的窗口,用于呼叫不同区域代码中的人员(在东部时区上午10点给某人打电话要比在太平洋时区早上7点给某人打电话要好得多.>性别：对于很多应用程序,将性别代码(‘M’或’F’)存储在表中是完全合理的.另一方面,有些情况下您可能需要其他选项(其他,Intersex,Transgendered)或您需要存储出生时的性别和当前性别等内容.

原文地址：https://www.jb51.cc/mssql/79950.html