数据库表列数据类型设计问题

Question

有时，片段数据可以表示为整数（4个字节）或字符串。示例：电话号码为bigint（8字节），邮政编码为int（4）等。我们有一个索引值描述三元组的大表作为3列，索引是一个5位整数（不是顺序），并且我们把它作为int。 DBA告诉我们这是一个糟糕的设计，应该总是使用varchar来保存这些数据，除非它可以是像auto-inc PK这样的保证整数。你同意吗？为什么或为什么不呢？

Answer 1

我的经验法则是，如果您不打算对其进行数学运算并且它不是代理键或代理键的fk，则它是字符串数据。电话号码不是整数，它们是字符串，与邮政编码相同（在美国BTW之外不是数字）。存储为字符串的数字通常具有并且需要前导零（请参阅美国邮政编码）将它们存储为INT或小数将不允许您输入有效值。如果它不是自动生成的，你怎么知道它需要是整数数据？如果你是100％肯定的，它应该永远不会是一个整数（并且没有前导零），使它成为一个int将防止一些不良数据进入。但是，真的很确定，你不需要做它后来的字符串数据（例如当你国际化并发现你的posal代码不再是数字时）。

为了提供有关您正在做的事情的更好建议，我需要一个更好的例子来说明您正在谈论的数据类型。您的表数据需求对我来说并不完全清楚。

Answer 2

如果您需要做的只是代表一个id，我建议不要使用VARCHAR作为索引列。首先，索引VARCHAR会产生不必要的处理开销。开销来自于以下事实：在进行索引编制之前，必须通过数据库COLLATION转换VARCHAR值。其次，没有理由拥有可变长度的数据类型 - 这会导致索引效率低下。第三，你需要5倍的空间来表示整数作为VARCHAR而不是INT。这意味着使用VARCHAR索引将增加5倍。最后，数字数据总是有可能蔓延到列中。这会破坏您的索引并可能破坏数据库的引用完整性。

Answer 3

如果DB是oracle，DBA可能是正确的。对于分区和索引，VARCHAR2类型可以比INT更有效。

此外，如果您不在INT字段上进行聚合或类似的操作，则无法获得收益。