SQL Server 数据类型：将 8 位无符号数存储为 INT 还是 CHAR(8)？

Question

我认为标题说明了一切。 将 8 位无符号数存储为 Int 类型还是 char(8) 类型更好（更快，根据内存和磁盘节省空间）？ 当我使用固定字符长度时，如果将来数字变为 9 位，我会遇到麻烦吗？

背景信息：我想存储 TAC

谢谢

Answer 1

鉴于 TAC 可以有前导零，它们实际上是一个不透明的标识符，并且永远不会用来计算，请使用 char 列。

在确定已正确建模数据类型之前，不要开始优化空间。

编辑

但是为了避免其中出现垃圾，请确保还应用了 CHECK 约束。例如，如果它是 8 位数字，请添加

CONSTRAINT CK_Only8Digits CHECK (not TAC like '%[^0-9]%' and LEN(RTRIM(TAC)) = 8)

Answer 2

如果是数字，则将其存储为数字。

整数使用 4 字节 存储，给出范围：

-2^31 (-2,147,483,648) 到 2^31-1 (2,147,483,647)

所以，适合您的需求。

char[8] 将存储为 8 个字节，因此存储量增加了一倍，当然还会受到将来扩展的需要（将近 10M 记录从 8 个字符转换为 9 个字符需要时间，并且可能需要在此期间使数据库脱机）。

因此，从存储、速度、内存和磁盘使用（所有这些都与数据类型使用的字节数有关）、可读性、语义和面向未来来看，int 毫无疑问胜出。

---

更新

既然您已经澄清您不存储数字，我想说您必须使用char来保留前导零。

至于未来扩展的问题 - 由于 char 是固定长度字段，因此从 char[8] 更改为 char[9] 不会丢失信息。但是，我不确定附加字符是否会添加在右侧或左侧（尽管这可能尚未确定）。您必须进行测试，一旦字段扩展，您将需要确保原始数据已被保留。

更好的方法可能是创建一个新的 char[9] 字段，将所有 char[8] 数据迁移到其中（以保持可靠和一致），然后删除char[8] 字段并将新字段重命名为原始名称。当然，这会破坏表中的所有统计数据（但直接扩展字段也会破坏）。

Answer 3

int 比 char 使用更少的内存空间并提供更快的索引。

如果您需要将这些数字分开 - 搜索数字 3-4 为“02”或类似数字的所有内容 - char 会更简单并且可能更快。

我猜你没有对它们进行算术运算。您不会将两个 TAC 添加在一起或查找一组记录的平均 TAC 或类似的内容。如果是的话，那将是使用 int 的有力论据。

如果它们有前导零，那么使用 char 可能更容易，因此您不必总是用零将数字填充到正确的长度。

如果以上都不适用，那也没有多大关系。我可能会使用 char。我想不出有什么令人信服的理由去选择任何一种方式。

Answer 4

对于这个，请坚持使用 INT，DEFFINITELY INT（或 BIGINT）

看一下 int、bigint、smallint 和tinyint (Transact-SQL)

-2^31 的整数（整数）数据
(-2,147,483,648) 到 2^31 - 1
（2,147,483,647）。存储大小为4
字节，

来自-2^63的bigint（整数）数据
(-9,223,372,036,854,775,808) 至
2^63-1 (9,223,372,036,854,775,807)。
存储大小为8字节。

相比

与char 和 varchar

固定长度非 Unicode 字符
长度为n个字节的数据。 n 必须是
1 到 8,000 之间的值。贮存
大小为 n 字节。

另外，一旦你对此进行查询，如果你使用 int 与你的 char 列相比，你的性能将会下降，因为 SQL Server 必须为你做 as 强制转换...