Sea*_*ley 51 database database-design types postal-code street-address
乍一看,我认为在数据库表中存储邮政编码有两个基本选择:
char(5)或varchar(9)支持+4扩展如果我们假设没有国际问题,两者都将满足数据的要求.在过去,我们通常只是走了文本路线,但我想知道是否有人做相反的事情？只是简单的比较看起来整数方法有两个明显的优点:
而且,它似乎不会对显示输出造成太大影响.打一个ToString()数值,使用简单的字符串操作来插入连字符或空格或其他任何+4扩展名都是微不足道的,并使用字符串格式来恢复前导零.
是否有什么可以阻止使用int仅限美国邮政编码的数据类型？
S.L*_*ott 118
数字邮政编码 - 以较小的方式 - 具有误导性.
数字应该意味着数字.邮政编码不会添加或减少或参与任何数字操作.12309 - 12345不计算从斯克内克塔迪市中心到我家附近的距离.
当然,对于邮政编码,没有人感到困惑.但是,对于其他类似数字的字段,它可能会令人困惑.
由于邮政编码不是数字 - 它们恰好用限制字母编码 - 我建议避免使用数字字段.1字节的保存不值得.我认为这个意义比字节更重要.
编辑.
"至于领先零......"是我的观点.数字没有前导零.邮政编码上存在有意义的前导零是另一个证明它们不是数字的证据.
Tom*_*Tom 24
你打算存储非美国邮政编码吗？加拿大有6个字符,有些字母.我通常只使用10个字符的字段.磁盘空间很便宜,不得不重做你的数据模型.
Mar*_*ark 17
使用带验证的字符串.邮政编码可以从0开始,因此数字不是合适的类型.此外,这适用于国际邮政编码(例如英国,最多8个字符).在不太可能的情况下,邮政编码是瓶颈,您可以将其限制为10个字符,但首先检查您的目标格式.
以下是英国,美国和加拿大的验证正则表达式.
是的,你可以填充以获得领先的零.但是,理论上你丢弃了可能有助于发生错误的信息.如果有人在数据库中找到1235,原来是01235,还是错过了另一个数字？
最佳实践说你应该说出你的意思.邮政编码是代码,而不是数字.你要加/减/乘/分邮政编码吗？从实际角度来看,排除延长拉链更为重要.
通常,您将使用非数值数据类型,例如varchar,这将允许更多的邮政编码类型.如果你只是允许5位[XXXXX]或9位[XXXXX-XXXX]邮政编码,你可以使用char(5)或char(10),但我不推荐它.Varchar是最安全,最理智的选择.
编辑:还应注意,如果您不打算对该字段进行数值计算,则不应使用数值数据类型.在您添加或减少邮政编码的意义上,邮政编码不是一个数字.它只是一个恰好由数字组成的字符串,因此您应该避免使用数字数据类型.
从技术角度来看,这里提出的一些观点相当微不足道.我每天都在处理地址数据清理- 特别是来自世界各地的清理地址数据.任何想象力都不是一项微不足道的任务.对于邮政编码,您可以将它们存储为整数,尽管它可能不是"语义上"正确的.事实上,数据是否为数字形式,严格来说,它被认为是数值的.
但是,将它们存储为数字类型的真正缺点是,您将无法轻松查看数据是否输入错误(即缺少值),或者系统是否删除了前导零,从而导致代价高昂的操作以验证可能无效邮政编码,否则是正确的.
如果其中一个影响是业务延迟,那么强制用户输入正确的数据也很困难.如果用户不是很明显,那么用户通常没有耐心输入正确的数据.使用正则表达式是保证正确数据的一种方法,但是如果用户输入的值不符合并且显示错误,则可能只是完全省略该值或输入符合但不正确的值.[使用加拿大邮政编码]的一个例子是您经常看到输入的A0A 0A0无效但符合加拿大邮政编码的正则表达式.通常情况下,这是由被迫提供邮政编码的用户输入的,但他们要么不知道它是什么,要么没有全部正确.
一个建议是验证整个条目作为一个单元,验证邮政编码与地址的其余部分相比是否正确.如果不正确,则为地址提供备用有效邮政编码将使他们更容易输入有效数据.同样,如果邮政编码对于街道地址是正确的,但街道号码不属于该邮政编码的域名,则为该邮政编码/街道组合提供备用街道号码.
小智 5
没有为什么