sql - 对一组数据使用整数而不是 varchar *真的*值得吗？

Question

例如，如果我有一个表 User，我想存储性别或性别，我将添加一个列，如 sex。

使用一个整数然后用我最喜欢的编程语言映射它真的值得吗？

像 1 => 'Male' 和 2 => 'Female'

这样做有任何性能原因吗？

或者我是否可以安全地使用 varchar，它更多 表示“女性”或“男性”，就像我使用 mysql ENUM 一样？

编辑:我在这里和那里有时更好，有时无关紧要，所以我更多地寻找基准或其他东西而不是“它更好”的答案。

我的意思是我认为使用 varchar 实际上比整数更有意义，只有当性能超过 0.3% 或其他东西时我才会使用整数。

Answer 1

如果这是为一些为 10 人服务的自制网站或应用程序，那么做任何你想做的事，性能不会有什么不同。

如果这是为了某些真实的东西，那么跳过你自己的性别实现并遵循 ISO standard for sex .或者至少遵守任何存在的标准(感谢 Joe Celko!)

0 = not known
1 = male
2 = female
9 = not applicable

始终调整您的数据类型

• 磁盘空间节省:
  在我上一份工作中，负责设计表格的迂腐人员创建了一个精度为 0 的十进制列，因为它应该只有 N 位数字。该数据类型与整数数据类型之间的存储成本差异为 1 或 2 个字节。但是，由于此表非常 很大，因此仅在表上使用较小数据类型所节省的总成本就以千兆字节为单位。

• 访问节省:大多数人没有考虑的第二个成本是从磁盘读取信息或将数据保存在内存中的成本。在 SQL Server 中，数据存储在 8K 页中。如果您使用的是胖数据类型，则需要更多的读取才能从磁盘中取出数据，然后您可以在内存中存储随后更少的数据页。 从磁盘中提取数据是您会产生最大性能成本的地方。如果您想加快使用数据库的速度，请不要破坏物理实现。

作为系统中覆盖问题域的最小允许类型来实现。对于性别之类的东西，请在 MySQL 中使用 tinyint( SQL Server ， Oracle )或数字(5,0)并且您将为每个性别花费 1 个字节的存储空间。

国际化

M = 男，F = 女，这似乎很明显。凡尔达？ Aqui, nosotros hablamos español。就我的西类牙语而言，这就是我的意思，但我的观点是，如果你需要多语言，1 将服务于男性、gentes、mannlich、masculin 等。M 或 Male 将只为讲英语的观众服务。此外，然后您会遇到奇怪的表示逻辑“我们需要翻译所有内容，除非它要成为 $culture”。将表示逻辑作为 UI 并将其置于数据库之外是一种更简洁的设计。