这不是循环引用。
如果电子邮件与邀请具有强完整性关系,并且邀请与电子邮件具有独立的强完整性关系(例如),这将是。
编辑:关于设计
正如 Henk Holterman 指出的那样,问题是您的设计是否已标准化到所需的程度。
模拟表:主键如
用户:id
电子邮件:id、users_id
邀请:id、users_id、emails_id
并假设 table_id 字段上的外键并且没有在表上放置其他约束(例如,只有键的一部分是唯一的),那么您已经对以下内容进行了建模:
- 对于每个用户,可以有多个电子邮件,并且您不能拥有没有相应用户记录的电子邮件
- 对于每封电子邮件,可以有多个邀请,并且您不能有没有相应电子邮件或用户记录的邀请(注意:根据上述定义,我们无法知道 user_id 是指电子邮件中的条目还是用户中的条目)
现在只有您可以说这些规则是否与您尝试建模的真实世界情况相对应。
查看数据库设计的一种方法是 - 实际上没有错误的数据库设计,您几乎总能找到可以使看起来像错误的数据合理的数据。这就是为什么如果不同时考虑规则(以句子的形式)和表格(ER图,表格和关系的描述),就不可能说设计中是否存在问题(尽管可以根据个人经验给出建议)。
为了说明 - 上面的注释不清楚 user_id 指的是哪个表似乎很容易回答。考虑到您说每个邀请都有一封邮件,常见的答案是它应该引用邮件表中的 user_id 。
否则,可能存在邀请中记录的 user_id 与邮件中记录的 user_id 不同的邀请。
通常,这应该会使标有“规范化您的数据”的红灯在您的脑海中闪烁。但是,这里通常不言而喻的假设是 email_id 决定了 user_id,这可能不是真的(!)。
这取决于您的数据的语义(每个表的谓词) - 例如,如果您尝试模拟可以向一个人发送邀请并接收另一个人的电子邮件回复的情况(例如通过秘书邀请人们并收到直接回复),然后红灯熄灭,一切都很好——这就是真正发生的事情,这就是你在设计中要允许的。