在数据库中定义数据类型时，我一直在选择是使用整数还是字符串来存储某些“数字”数据时遇到问题。
假设我正在构建 Yet Another Address Book 并且有一个邮政编码字段。如果邮政编码始终是一个 4 位数字，我将其存储为哪种数据类型？整数还是字符串？从技术上讲，它是一个整数，但我没有对它进行任何类型的计算，我只是把它吐到一张桌子上。如果我想按邮政编码对表格进行排序，您的意见会改变吗？
现在，我并不傻。我确实认识到对整数的有效需求，例如页面浏览量和唯一用户或登录用户和访客用户。但是如何存储洪流中的文件数量呢？整数还是字符串？
【问题讨论】：
标签： database language-agnostic database-design
在我的国家，邮政编码也总是 4 位数字。但是第一个数字可以是零。
如果将“0700”存储为整数，会出现很多问题：
从技术上讲，我们的邮政编码实际上是字符串，即使它始终是 4 位数字。
您可以将它们存储为整数，以节省空间。但请记住，这是一个简单的 DB 技巧，请注意前导零。
但是存储多少呢？ 文件在洪流中？整数或 字符串？
这显然是一个整数。
【讨论】：
我总是使用以下规则：
如果您打算对其进行数学计算（加/减/等），请将其设为整数或其他数值数据类型。
如果您不打算对该字段执行任何类型的数学计算，请将其存储为字符串。
在邮政编码的例子中，您永远不会有需要将两个邮政编码相加、相减或相乘的情况。数学函数通常不用于邮政编码，因为它们用作标识符而不是数量。因此，您应该将邮政编码存储为字符串数据类型
【讨论】：
在我看来，对于邮政编码，您必须使用字符串，因为您可以使用以零开头的邮政编码 (09100)，如果您使用整数，则为 9100：排序不是问题，因为仍有字母顺序顺序（“09100”在“09101”之前）。 对于存储文件编号，我希望有一个整数，所以你在增加/减少它的数量时没有任何问题。所以整数与字符串取决于你的用途！
【讨论】：
这是一个语义问题。您正在尝试确定合适的存储数据类型，这可能是一个棘手的问题。如果您需要将数据用作整数，最好的经验法则是将数据存储为整数。
换句话说，由于您永远不会将邮政编码用作数字，因此将其存储为数字是没有意义的。数据看起来是什么样的并不重要，重要的是它是什么。邮政编码是数字吗？不，它是一串字符，恰好由全数字字符组成。因此，邮政编码最好存储为字符串。
【讨论】：
就邮政编码而言，这是典型的英国邮政编码：
EC2R 6PK
在大学时，我的数据库讲师告诉我一些令我印象深刻并在 15 年后仍然存在的事情：
如果你对其进行算术运算，存储 它作为一个数字。否则它是一个 字符串。
坦率地说，我认为你不会听错这个建议。
显然您不对邮政编码执行算术运算，因此它们是字符串。
【讨论】：
邮政编码不是数字：它是代码或标识符。这同样适用于电话号码。
一个种子文件的数量是一个整数。
同样重要的是，在这种情况下，您可以创建 CHECK CONSTRAINT LIKE '[09][09][09][09]' 以在数据库级别保持数据正确。
【讨论】：
对于邮政编码，我会选择一个字符串。它本质上不是整数。它只是某事物的标识符，也可以是一系列四个字符。
种子里面的文件数，应该是整数。
【讨论】：
“0000”是邮政编码吗？它与“0”不同吗？
如果它始终是一个四位数字，我将始终将其存储为 4 位数字，这意味着将其保留为字符串。
【讨论】：
除非我希望对数据进行数学运算，否则我不会使用数值数据类型。为什么要冒险为您“确定”的事物在将来发现问题总是有人决定放入非数字字符的数字。
如果您不打算对其进行数学运算，请将其设为字符串。
【讨论】：
请记住，并非所有国家/地区的所有邮政编码都只是数字。仅仅因为您现在在加拿大没有任何地址并不意味着您将没有任何地址。我一直遵循规则，如果你想进行数学计算，将其存储为数字类型，如果它只是一个代码（邮政编码、电话、SSN、零件号等），那么我将其存储为字符串。您要避免的是每次调用时将数据不必要地转换为另一种格式（例如，如果您将邮政编码存储为数字，则添加前导零的代码或将字符串转换为数字以进行计算的代码）。如果您需要重复执行这些操作，这些操作可能会很昂贵，尤其是当表很大并且您最终不得不在 where 子句中进行转换时。以您需要的方式存储数据要好得多。
【讨论】：
我认为将邮政编码存储为数字没有问题，即使您不希望对其执行数学运算。
在我们的企业数据仓库中，我们是来自许多旧系统的数据的接收者。结果，我们看到大量垃圾数据被使用。
以我们的例子为例，我们有一个地理标识符，它是一个由 0 填充的 4 位“数字”值。该字段通常用于将表连接在一起。
我会采取以下两种方法之一： 1) 将该列声明为长度为 4 的 char 字段并添加 CONSTRAINT LIKE '[09][09][09][09]' 2) 将其定义为数字长度 4，如果用户需要，请仅在显示时格式化该值。
接近数字 1 为您省去了不断格式化的麻烦，这没什么大不了的，但如果您经常过滤甚至索引/加入列，我会考虑说我们不使用选项 #2。
第三个原因是我的经验是人们在向数据库添加约束时只是很懒惰，或者他们是无知的。我个人认为这更多的是懒惰。我发现确实存在的约束主要是作为最初捕获数据的应用程序中的编辑应用的，而这些编辑并没有统一应用。
因此，我们的数据仓库最终会收到各种变化，包括不一致的预填充零或值的调整。
当您将某些内容定义为 INTEGER 时，您会自动获得更高效的存储，尤其是。在对列进行索引和编辑时，每个人都理解并且更有可能被具有各种能力的数据库设计人员在遗留系统中一致地应用。
我对选项 #1 没有任何问题，除了在索引中使用该字段以及我对一旦您接受一个字段作为 apha 数字的方法的担忧，人们往往会往里面扔更多的垃圾。
以我们的 Peoplesoft 员工标识符为例。有人决定在员工 6 字符零填充的“数字”前面添加一个“X”，以指定该员工是承包商。这违反了我的个人习惯，即不将单独的信息组合到一个字段中。这导致了各种系统之间的各种不一致问题。如果这个字段是一个数字，没有人会尝试这样做。
评论？
【讨论】：
邮政编码是字符串。对于某些国家，这些字符串可能只包含数字，但这并不会使它们成为整数。迟早你的potal系统会用完数字并决定开始使用字母。如果您的数据库使用整数作为邮政编码字段，那么您将陷入困境。
底线 - 如果你不对其进行算术运算，它可能不是真正的数字。
【讨论】：
关键的决定因素，恕我直言，是应用程序是否需要对值进行数值算术计算，如果不需要，那么使用整数的唯一原因是减少存储要求，（“可能”对性能很重要在关键应用程序中——例如，通过减小表索引的宽度来提高索引性能）但除此之外，通常并不重要……
如果不需要对这些值进行算术运算，那么最好使用字符串。
【讨论】：
有时“总是”的意思是“下个月”。在我的职责范围内，我不会指望 4 位代码不会变成字母数字。
某些 SQL 方言支持类似于 NUMBER(4) 的数据类型。这很像字符串，但字母表是 0 到 9。
【讨论】：
了解您正在使用的数据的语义始终很重要。让我在例子中解释一下。
考虑您希望将 PIN 存储在数据库中。要回答您应该使用什么数据类型，您必须首先回答 PIN (Personal identification number) 的真正含义。
如果它真的是一个数字，正如它的名字所表明的那样，那么我看不出有什么理由不应该将它表示为整数。
有些人可能会争辩说你无法区分 0001 和 01。显然他们不认为 PIN 是一个数字，如果他们使用这种语义，他们应该使用字符串。
注意：如果 PIN 长度固定为 4 位数字，他们仍然可以使用整数，因为任何数字都将始终用前导零填充，并且含义完全相同（0001 将相同如 01) - 但这些固定长度限制通常用于数字以避免错误输入。*
如果语义清楚地表明 PIN 是一个数字，即 PIN 0001 与 PIN 01 完全相同，我将使用整数表示。
因此，在您的情况下，了解 postal code 语义很重要。语义在不同的国家可能会有所不同（甚至会随着时间而变化），因此您要使用哪个也很重要。为了涵盖所有类型的邮政编码甚至可能的更改，我会考虑使用更抽象的数据类型或仅使用字符串（我相信已经存在包含更多字符而不仅仅是数字的语义）。
我不建议遵循简化规则，例如关于数据表示上的算术运算的规则。如果您现在不想对数据执行数学运算并不意味着您将来有时也不想。
您有数据并且想要存储它，以某种方式表示它 - 只需想想您正在处理的是什么。
【讨论】：
只有在必须对数字字段执行算术运算时才应使用数字字段。否则就使用 string/varchar/etc
【讨论】：