为什么在设计数据库关系时应该避免循环？
有人告诉我，数据模型中存在循环是糟糕的设计。我以前听过这句话好几次，但并没有太在意。例如，您有实体“用户”、“项目”、“活动”。项目由用户拥有，因此用户与项目之间存在一对多关系。活动可以分配给单个用户，这是从用户到活动的另一种一对多关系。当然，项目是由一组活动定义的，这是从项目到活动的另一种一对多关系。这样就形成了一个循环。
我问这个人为什么设计不好，但他告诉我他也不知道，他也被告知，猴子学习是最好的。
我尝试搜索，但我想我没有使用正确的词语，但是在我看来，这对于尝试设计数据库的人来说应该是基础。
那么，有人可以向我指出一些有关 er/db 图中循环/周期的有用信息吗？应该避免它们吗？
Someone told me that it was bad design to have loops in the datamodel. I have heard this before a couple of times but didn't pay much attention. For example you have entities User, Project, Activity. A project is owned by a User, so we have a one-to-many relationship from user to Project. An activity can be assigned to a single User, another one-to-many relationship from User to Activity. Of course a project is defined by a set of activities, another one-to-many relationship from Project to Activity. Thus a loop is formed.
I asked this guy why is it bad design but he told me he didn't know either, he was told so too, monkey learning at it's best.
I tried searching but I guess I didn't use the proper words, however this seems to me something that should be fundamental for someone trying to design a DB.
So, can anyone point me to some useful info about loops/cycles in er/db diagrams, should they be avoided?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
本文 (archive.org）。
然而，一般来说，循环最常见的问题是冗余信息的一致性。
考虑一下（来自论文）父母有很多孩子的情况；每个孩子都上学。父母与父母之间还有第三种关系。学校（“父母有孩子在学校”）。但是：您不想显式地建模第三种关系；它完全可以从其他两个派生出来。如果您确实明确捕获了它，则需要确保循环始终一致。
所以在这种情况下你会想要避免循环。然而：循环并不总是不好的。再次以上面的例子为例，考虑对家长是学校管理者的情况进行建模。这也会造成一个循环。在这种情况下，它是有效的：不可能从其他两个关系中得出“父母是学校的州长”关系。
总而言之：当一种关系完全可以从其他关系组合中派生时，不要对循环进行建模。但当循环不可导出时，创建循环是可以的。
不过会推荐这篇论文；它给出的描述比我在这里给出的要好得多。
There's a really good treatment of relationship loops in chapter 3 of this paper (archive.org).
Generally however, the most common issue with loops is consistency of redundant information.
Consider the case (from the paper) where a parent has many children; each child attends a school. There is a third relationship between parent & school ('parent has child at school'). However: you don't want to model the 3rd relationships explicitly; it's completely derivable from the other two. If you did capture it explicitly, you'd need to ensure the loop was always consistent.
So in that case you'd want to avoid the loop. However: loops are not universally bad. Taking the above example again, consider modelling the case where a parent is a governor at a school. That would also create a loop. In this case though it's valid: it's not possible to derive the 'parent is governor at school' relationship from the other two relationships.
So in summary: don't model loops when one relationship is completely derivable from the others combined. But it's OK to create loops when they're not derivable.
Would recommend the paper though; it gives a much better description than I can give here.