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

Question

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

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

存储string而不是int时出现的明显缺陷是：

• 标准化不佳。
• 桌子尺寸更大。
• 如果需要重命名特定列值，则更新速度较慢。

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

• 除了我刚才提到的3点之外，你有没有理由存储字符串而不是整数。

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

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

• 是否有任何类型的＆＃34;拇指规则＆＃34;我应该知道吗？

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

Answer 1

非常感谢您提出这样一个非常有用的问题

• 整数可以作为字符串存储 - 如果在列中存储金额值并且需要在整数值（10,000）之间保持逗号，则可以使用字符串列，因为整数忽略逗号
  如果是在值中保持趋势零，可以使用字符串列。使用整数列时
将截断不需要的十进制零

• 创建索引以调整数据库中的数据检索。与字符串列相比，与数字列相比，在整数列上创建索引的速度要快一些。
  这些时间的变化只是一个毫秒的差异。即使将字符串列更改为整数，也不会产生很大的不同。但是，如果您需要更改，您只需使用查询转换索引数据类型，

  CREATE INDEX INDEX_NAME ON COLUMN_NAME(TO_NUMBER(COLUMN_NAME))
  

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

希望你对答案感到满意

Answer 2

关于规范化：

只要给定表的每一列都依赖于密钥，整个密钥而不是密钥，您可能没有规范化问题。

假设您有一个包含国家/地区名称country的表格。没有必要在该表中添加代理键（例如整数id） - 现实世界中存在一个非常好的密钥（请参阅我在那里所做的）。单列= country_name

假设您有另一个名为city的表格，其中有两列：country_name，city_name。该表的关键只是两列。您需要city.country_name引用country.country_name的外键约束。如果没有它，你可能会遇到规范化问题。

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