sql – 存储查找表id或纯数据之间的决定

我的问题是如何在使用外键查找表之间做出决定,或者直接在请求表的表中使用查找表值,完全避免查找表关系.

要牢记：

你可以用第二种方法
需要对所有人进行大规模更新
记录参考资料
在查找表中更改.
>这更集中
对于有很多的表
该列引用许多查找
所以很多外国人
键意味着很多
每次查询时加入
表.
>这个数据将来自下降
下拉列表将被拉
从查找表.为了在重新加载时匹配数据,这些值需要在现有列表中(与第一个点相关).

这里有最佳实践,还是要考虑的要点？

解决方法

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行表中的主键大小并不重要.但是该查找表可能在其他表中的数百万或数十亿行引用！

所有案件都没有正确的答案.对于不同的情况,任何答案都是正确的.您只需了解权衡,并逐案作出明智决定.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!