sql - 存储查找表ID或纯数据之间的决定

我发现这个问题很多，而且我不确定解决这个问题的最佳方法。

我的问题是如何在使用外键查找表还是直接在请求表中使用查找表值之间做出决定，从而完全避免查找表之间的关系。

注意事项:

使用第二种方法，您将
需要对所有人进行批量更新
记录引用数据(如果有)
在查找表中更改。

这是重点
对具有很多
该列引用多次查找
表。因此很多外国
键意味着很多
每次您查询
表。

该数据将来自下拉
下拉列表将被拉
从查找表。为了在重新加载时匹配数据，这些值需要在现有列表中(与第一点有关)。

这里是否有最佳实践，或要考虑的任何关键点？

最佳答案

您可以使用具有VARCHAR主键的查找表，主数据表的列上使用FOREIGN KEY，并具有级联更新。

CREATE TABLE ColorLookup (
  color VARCHAR(20) PRIMARY KEY
);

CREATE TABLE ItemsWithColors (
  ...other columns...,
  color VARCHAR(20),
  FOREIGN KEY (color) REFERENCES ColorLookup(color)
    ON UPDATE CASCADE ON DELETE SET NULL
);

该解决方案具有以下优点:

您可以查询主数据表中的颜色名称，而无需连接到查找表。

不过，颜色名称被限制为查找表中的颜色集。

您可以通过查询查询表来获得唯一颜色名称的列表(即使主数据中当前未使用任何颜色)。

如果更改查找表中的颜色，则更改将自动级联到主数据表中的所有引用行。

令我惊讶的是，在此线程上有这么多其他人似乎对“规范化”是错误的观念。使用代理键(普遍存在的“id”)与规范化无关!

来自@MacGruber的评论:

是的，大小是一个因素。例如，在InnoDB中，每个辅助索引都存储给定索引值所在行的主键值。因此，拥有的二级索引越多，对主键使用“大量”数据类型的开销就越大。

这也会影响外键；外键列必须与其引用的主键具有相同的数据类型。您可能有一个小的查询表，因此您认为50行表中的主键大小无关紧要。但是该查找表可能被其他表中的数百万或数十亿行引用!

对于所有情况，都没有正确的答案。对于不同情况，任何答案都是正确的。您只需了解权衡，然后尝试逐案做出明智的决定。

关于sql - 存储查找表ID或纯数据之间的决定，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/383026/