MySQL - "Lookup"列数据类型 - 存储简单查找的理想方式

标签 mysql database database-design relational-database innodb

我在工作中听一些人谈论数据库专栏。 本质上,我们想添加一个新列作为查找表的 FK。它基本上是您首选的联系方式(主要电话或主要电子邮件)。所以主表 'User' 有一个 FK 到 'PreferredContactMethod'

第 1 个人: “让我们将 FK 列存储为一个无符号的 tiny int,并使 PK 查找表只包含一个 tinyint PK 和一个文本描述/代码”

第 2 个人 “在 MySQL 中,我们将数据类型存储为 unsigned tinyint 还是 char(x) 是无关紧要的,那么为什么必须进行连接以找出查找列的值是什么?相反,使 FK 成为char(x),并在实际表上进行PK char(x)”

第 3 个人 “不,将 PK 表示为字符不是一个好主意。它效率不高。处理像 unsigned tinyint 这样的东西比文本更好。而且由于只有两个值,我们为什么不将它存储为一个列(不是 FK),值为 0 或 1。这样效率更高,您无需加入任何内容。”

所以在听了这一切之后,我开始怀疑谁是对的。我怀疑这是微不足道的,以至于它在性能方面无关紧要,但我现在很好奇它的优缺点是什么,我希望有人能接受它。

感谢您的宝贵时间。

最佳答案

像这样的问题通常没有正确或错误的答案。或者实际上,任何一个答案都可能是正确的,因为这取决于您将如何使用数据。

将 int/tinyint 存储到查找表的一个很好的例子是值定期更改,并且您希望允许在查找表中发生更改而不更改引用它的所有行。

如果您有一个不经常更改的相对较小的查找表,并且字符串相当短,那么将 PK 存储为字符串是一件好事。如果字符串很长,这可能会使 FK 引用变得更笨重,并占用大量空间。

将 PK 存储为字符串的低效率不会对查找表产生太大影响。那张 table 很小。字符串 PK 的成本主要是由于频繁的随机插入。但这不会影响查找表。

关于MySQL - "Lookup"列数据类型 - 存储简单查找的理想方式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43011564/

相关文章:

mysql - 仅在一个数据库上授予文件

mysql - 在 Heroku 的 Play Framework 1.2 上部署 Java 应用程序,如何确保它可以处理更高的负载?

数据库设计关系代数查询

database - 如何更好地组织数据库以说明用户状态的变化

php - 针对一些未知数据的数据库表设计

mysql - 喜欢的帖子设计细节

php - 如何将ajax添加到wordpress主题

mysql - 带线程的 Perl 邮件队列 'out of memory'

php - 最好运行 2 个 sql 查询或 1 个并处理重复的结果集?

database - Firebird 使用 isql 从一个数据库复制