在表中存储整数而不是实际字符串的优点/缺点

Posted 2023-05-08

【中文标题】在表中存储整数而不是实际字符串的优点/缺点

【英文标题】：Advantages/disadvantages of storing an Integer instead of the actual string in a table

【发布时间】：2016-09-13 09:57:23

【问题描述】：

有人要求我重新设计现有数据库，我注意到其中一件事是它们将所有下拉值存储为字符串而不是 int。

作为一种习惯，我总是将组合值存储在一个表中，并将每个字符串与特定的 Id 相关联，并将 Id 值存储在用于搜索的元数据表中。然后在搜索相关值时使用INNER JOIN，但我想先检查一下是否存在您最好存储字符串的情况。

在存储 string 而不是 int 时想到的明显缺陷是：

标准化不佳。 更大的表格。 如果需要重命名特定列值，更新速度会变慢。

我不确定的点是（大规模，即数百万条记录）：

除了我刚才提到的 3 点之外，您还有什么理由要存储字符串而不是整数。

索引如何受此影响？更大？慢一点？

直接针对特定字符串运行查询，而不是针对另一个表使用INNER JOIN 以将相关字符串与与此相关字符串关联的整数值进行匹配是否更快？

有什么我应该注意的“经验法则”吗？

在使用一种方法或另一种方法时，我还应该注意其他优点或缺点吗？

【问题讨论】：

我会坚持你的习惯。你的明显缺陷很明显。

【参考方案1】：

关于标准化：

只要给定表的每一列都依赖于键、整个键且仅依赖于键，那么您可能不会遇到规范化问题。

假设您有一个包含国家/地区名称country 的表。无需向该表添加代理键（例如整数 id） - 现实世界中存在完美的键（看看我在那里做了什么）。单列=country_name

假设您有另一个名为 city 的表，其中包含两列：country_name、city_name。该表的关键是两列。您需要一个外键约束，其中city.country_name 引用country.country_name。否则，您可能会遇到规范化问题。

将country_name 直接放在city 表中的好处是您不必执行连接。缺点是如果国家名称发生变化，您必须更新一堆城市行。还要考虑额外的表宽度（字节）和索引宽度（字节）。根据您的桌子的宽度，这可能/可能不是问题。

【参考方案2】：

整数可以存储为字符串 - 如果在列中存储金额值并且需要在整数值 (10,000) 之间保留逗号，您可以使用字符串列，因为整数忽略逗号

在值中保持趋势零的情况下，可以使用字符串列。使用整数列时，不需要的十进制零将被截断

创建索引是为了调整从数据库中检索的数据。虽然与数字列相比，在整数列上创建索引要快一点，但与字符串列相比也是如此。

这些时间限制的变化只是毫秒的差异。即使您将字符串列更改为整数，也不会产生太大的影响。但是如果你需要改变，你可以只用查询转换索引数据类型

  CREATE INDEX INDEX_NAME ON COLUMN_NAME(TO_NUMBER(COLUMN_NAME))

使用连接是从数据库中检索数据的最快方法，而不是使用子查询

【讨论】：

我想你误解了我的问题。我不想将整数存储为字符串，而不是字符串。假设您有一个 Orders 表，例如，它包含 5 个“Hamburgers”订单。我不会创建 5 行并将其 ProductName 设置为“Hamburger”，而是将 ProductId 设置为与 Products 表中的“Hamburger”关联的 Id。这是我要询问的部分，即存储 ProductId 是否总是更好，或者有时仅存储实际字符串（即在这种情况下为 Hamburger）是否更好。这更有意义吗？