我不确定如何问这个问题，因此我将通过一个例子来使我尽可能清楚。
在诸如facebook之类的应用中，一个配置文件可以具有多个ProfilePictures。在任何给定时间，其中之一就是“选定的” ProfilePicture(假设ProfilePicture已上传)。
本能地，我会像这样建模:
Table: Profile
--------------
ProfileID
SelectedProfilePictureId //fk to ProfilePicture
Name, Age, Etc
Table: ProfilePicture
---------------------
ProfilePictureId
ProfileId //fk to Profile, indicating which Profile this picture belongs to
Url, DateTaken, Etc
此时，这些表相互指向，对我来说似乎“错”了。它使查询没有SelectedProfilePictures的Profiles或获取Profile的SelectedPicture变得很容易，但是插入和更新有点奇怪。
这是不好的形式吗？ Profile表是否应该完全独立于ProfilePicture表？是否有根据数据库设计理论对此建模的“正确”方法，还是由程序员决定？
最佳答案
没错，这称为循环引用，实际上您无法使数据库执行此操作。
一种简单的解决方案是在图片的子表上使用“preferred”标志。但是您这里有一个业务逻辑问题:给定人员只能选择一行。因此，当任何人将一个新的标记为首选时，您都必须清除其他任何一个。
一个更安全的解决方案是向Profiles和ProfilePictures添加带有外键的第三个表“preferredPictures”。使它在profileId上唯一，因此它永远不能有多个条目。这将迫使在插入新条目之前删除先前的条目。或者，当然，您可以仅对现有产品进行更新。
编辑:以回应评论。
1)没有循环引用，因为Profiles是两个子表的父级，因此不会循环到Profiles
Profiles
| |
| +-----> PreferredPicture
| +----->
| |
\|/ |
ProfilePictures
2)Preferred Picture的主键是ProfileId，从技术上讲，它是Profiles的1:1子表。
关于sql - 模式:双向关系？哪个表/实体应拥有 'preference'？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4909892/