我有需要存储的产品的id值。现在它们都是整数，但我不确定将来的数据提供者是否会在该混合中引入字母或符号，所以我在争论是将它现在存储为整数还是字符串。
将值保存为字符串是否存在性能或其他缺点？
答案 0 :(得分：27)
除非你真的需要整数的功能（也就是算术的能力），否则你最好将产品ID存储为字符串。您永远不需要做任何事情，例如将两个产品ID一起添加，或计算一组产品ID的平均值，因此不需要实际的数字类型。
将产品ID存储为字符串不太可能导致性能上存在可测量的差异。虽然存储大小会略有增加，但产品ID字符串的大小可能远小于数据库行其余部分的数据。
如果数据提供者决定开始使用字母或符号字符，今天将产品ID存储为字符串将为您节省很多痛苦。没有真正的缺点。
答案 1 :(得分：15)
不要考虑表现。考虑意义。
ID“数字”不是数字，除非它们是用所有数字的字母写的。
如果我的零件号为12，零件号为14，那两者有什么区别？第2或第2部分是否有意义？否。
零件号（以及没有度量单位的任何东西）不是“数字”。它们只是数字串。
例如，美国的邮政编码。电话号码。社会安全号码。这些不是数字。在我的城镇，邮政编码12345和12309之间的差异不是从我家到市中心的距离。
不要将数字与单位混淆 - 其中总和和差异意味着带有数字字符串的东西，没有总和或差异。
部件ID号码 - 正确 - 字符串。不是整数。他们永远不会是整数，因为他们没有总和，差异或平均数。
答案 2 :(得分：3)
这实际上取决于你在说什么类型的id。如果它是一个类似电话号码的代码，实际上最好使用varchar作为id，然后将自己的id作为db的序列并用于主键。在整数没有数值的情况下，通常优选变量。
答案 3 :(得分：3)
我刚刚在去年处理了一个数据库，该数据库几乎所有ID都是字符串，有些只有数字，有些则是混合的。这些都是问题：
当然，如果您的ID用完了，或者不知道如何创建新ID，那么您的应用就已经死了。我建议如果你无法控制传入ID的格式，那么你需要创建自己的（数字）ID并将用户提供的ID与之相关联。然后，您可以确保您自己的ID可靠且唯一（和数字），但提供用户可查看的ID，该ID可以包含您的用户想要的任何格式，甚至不必在整个应用程序中是唯一的。这是更多的工作，但如果你经历了我所拥有的，你就知道要走哪条路。
Anil G
答案 4 :(得分：1)
我不确定数据库在比较一个字符串是否大于另一个字符串时有多好，就像它可以用整数一样。尝试这样的查询：
SELECT * FROM my_table WHERE integer_as_string > '100';
答案 5 :(得分：1)
整数占用的空间比字符串少得多。例如2 ^ 32-1 = 4,294,967,295。这将需要10个字节来存储，其中整数将需要4个字节来存储。对于单个条目，这不是很大的空间，但是当你开始数以百万计时......正如许多其他帖子所暗示的还有其他一些问题需要考虑，但这是字符串表示的一个缺点。
答案 6 :(得分：1)
另一方面，这取决于你的情况。如果您打算存储电话号码或学生注册号码等内容，那么使用字符串就非常有意义了。
答案 7 :(得分：0)
从存储和性能角度来看，整数更有效。但是，如果可能引入字母字符的可能性很小，那么您应该使用字符串。在我看来，效率和性能优势可能微不足道，而修改代码所需的时间可能不是。
答案 8 :(得分：0)
正如Integer vs String in database
所述在我的国家/地区，邮政编码也始终为4位数。但第一个数字可以为零。
如果将“0700”存储为整数，则可能会遇到很多问题：
它可以被读作八进制值 如果它被正确读取为十进制值，它将变为“700” 当您获得值“700”时，您必须记住添加零 我不添加零，稍后，你怎么知道“700”是“0700”，还是有人输错了“7100”？ 从技术上讲，我们的邮政编码是实际的字符串，即使它总是4位数。
您可以将它们存储为整数，以节省空间。但请记住，这是一个简单的DB技巧，并且要注意引导零。
但是如何存储torrent中有多少文件呢？整数还是字符串？
这显然是一个整数。
如果ID从零开始，则将其存储为整数。
答案 9 :(得分：0)
更好地使用独立ID并在必要时添加字符串ID：如果需要包含业务指标，为什么要将其作为系统ID？
主要缺点：
整数运算和索引总是在大规模数据上表现出更好的性能（表中超过1k行，更不用说连接表了）
您必须进行额外的检查以限制列中仅限数字的值：无论是在客户端还是数据库端，这些都可以是正则表达式。无论如何，你必须以某种方式保证实际上是整数。
您将为开发人员创建额外的上下文层，而且无论如何总会有人搞砸了这一点：）