我发现这很多,我不知道最好的方法来处理它.
我的问题是如何在使用外键查找表之间做出决定,或者直接在请求表的表中使用查找表值,完全避免查找表关系.
要牢记：
你可以用第二种方法
需要对所有人进行大规模更新
记录参考资料
在查找表中更改.
>这更集中
对于有很多的表
该列引用许多查找
所以很多外国人
键意味着很多
每次查询时加入
表.
>这个数据将来自下降
下拉列表将被拉
从查找表.为了在重新加载时匹配数据,这些值需要在现有列表中(与第一个点相关).
这里有最佳实践,还是要考虑的要点？
解决方法
您可以使用具有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行表中的主键大小并不重要.但是该查找表可能在其他表中的数百万或数十亿行引用！
所有案件都没有正确的答案.对于不同的情况,任何答案都是正确的.您只需了解权衡,并逐案作出明智决定.
