乍一看，我似乎有两种基本的存储选择邮政编码 http://en.wikipedia.org/wiki/ZIP_code在数据库表中：
- 文本（可能是最常见的），即
char(5) or varchar(9)支持+4扩展
- 数字，即 32 位整数
如果我们假设没有国际问题，两者都满足数据要求。过去我们通常只走文字路线，但我想知道是否有人采取相反的做法？从简单的比较来看，整数方法有两个明显的优点：
- 就其本质而言，它自动仅限于数字（而未经验证，文本样式可以存储字母等，据我所知，这些字母在邮政编码中永远无效）。这doesn't不过，这意味着我们可以/会/应该放弃正常验证用户输入！
- 它占用的空间更少，为 4 个字节（即使对于 9 位邮政编码也应该足够），而不是 5 或 9 个字节。
而且，它似乎不会对显示输出造成太大影响。打一巴掌是小事ToString()对于数值，使用简单的字符串操作来插入连字符或空格或任何 +4 扩展名，并使用字符串格式来恢复前导零。
有什么会阻止使用int作为仅适用于美国的邮政编码的数据类型？
数字邮政编码在某种程度上具有误导性。
数字应该有意义numeric。邮政编码不进行加减或参与任何数字运算。 12309 - 12345 不会计算从斯克内克塔迪市中心到我家附近的距离。
诚然，对于邮政编码，没有人会感到困惑。然而，对于其他类似数字的字段，它可能会令人困惑。
由于邮政编码不是数字（它们只是碰巧使用受限字母进行编码），因此我建议避免使用数字字段。节省一个字节并没有多大价值，我认为meaning比字节更重要。
Edit.
“至于前导零......”是我的观点。数字没有前导零。邮政编码中有意义的前导零的存在再次证明它们不是数字。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
