是否可以有“捷径”？引用跳过表关系？
抱歉，
我有以下关系，一个盒子属于一个插槽，一个属于一个架子，一个属于一个冰箱。相反，冰箱有很多架子，有很多槽，有一个盒子。
对于某些操作，不需要知道盒子在冰箱内的位置。如果我有一条从盒子到冰箱的捷径，这会简化一些查询。
在盒子表中放置冰箱的外键是不是很糟糕？如果是的话为什么？
Sorry for the title
I have the following relation, a box belongs to a slot, that belongs to a rack, that belongs to a fridge. The other way around, Fridges have many Racks, that have many slots, that have one box.
For some operations, knowing where the box is within the fridge is not necessary. It would simplify some queries if I had a short-cut from boxes to fridges.
Is it bad, and if so why, to have a foreign key to the fridge in the boxes table?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这可能取决于关系更新的频率。如果关系可能经常更改，那么您将需要在多个位置更新关系，从而产生开销。这也会使事情变得稍微困难一些，因为如果您更改一个，则必须确保所有出现的情况也都更新。
但是，如果这些值不会经常更改，那么它似乎可以使您的查询更快。
这看起来是数据库规范化的一个很好的例子，他们使用的例子相当不错接近你的。如果您对标准化感兴趣，Wikipedia 关于此的文章非常好。
It could depend on how often the relation will be updated. If the relation is likely to change frequently then you would have the overhead of having to update the relationship in several places. This can also make things slightly more difficult too because if you change one you have to make sure that all occurrences are updated as well.
However, if the values are not going to change that often it seems like it could make your queries faster.
This looks like it is a pretty good example of database normalization and the example that they use is fairly close to yours. If you are interested in normalization the Wikipedia article on this is really good.
通过在两个不同的地方记录冰箱与盒子的关联，您可能会产生矛盾。因此，您要么必须创建额外的约束逻辑以确保冗余数据一致，要么接受数据可能是错误的。
By recording the fridge association with a box in two different places you create the possibility of a contradiction arising. Therefore you would either have to create extra constraint logic to ensure the redundant data was consistent or accept that the data might be wrong.