设计表:同时进行一对多和一对一?
我不确定我是否正确地建模了这种类型的关系,也许有人可以提供一些关于这是否合理的见解:
假设我们有一种典型的亲子关系,其中每个父母都可以有很多孩子,但是我们需要跟踪父级的单个(喘息)最喜欢的子级...
表父级
-FavoriteChildID
和
表子级
-ParentID,
因此链接是纵横交错的,其中一个是多对一,另一个是一对一。这被认为是好的设计吗?在子表中有一列,在任何时候只能将一行标记为收藏夹,这样会更好吗?还有别的事吗?
谢谢。
I'm not sure if I'm modeling this type of relationship correctly, perhaps someone could provide some insight into whether or not this is sound:
Say we have a typical parent-children type relationship where each one parent could have many children, but we need to keep track of the parent's single (gasp) favorite child...
Table Parent
- FavoriteChildID
and
Table Child
- ParentID
so the links criss-cross, where one is a many to one, and the other is one to one. is this considered good design? Would it be better to have a column in the child table where only one row could be flagged a favorite at any time? Something else?
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
再加一张桌子怎么样?
如果对于所有以收藏夹为导向的查询,这将会有所帮助。
How about an additional table?
It would help if for all favourite-oriented queries.
我认为最好的设计是能够防止数据不一致并防止人们有足够的绳子上吊自杀的设计。
如果您只想为父级添加一个收藏夹,那么父级可能应该有一个 favoriteChildId 列。
如果您在子项中放置一个收藏标记列,则必须做更多工作以确保同一父项的两个子记录不能同时被标记为收藏项。
如果您怀疑将来您可能会拥有不止一个最爱,那么额外的工作当然是值得的。
设计实际上取决于关系以及未来是否可能改变不同“最喜欢的”关系的可能性。
The best design in my opinion is the one that will prevent data inconsistencies and prevent people from having enough rope to hang themselves.
If you only want one favorite for a parent, then perhaps the parent should have a favoriteChildId column.
If you put a column for a favorite flag in the child, you'll have to do more work to ensure that two child records of the same parent can't both be marked as favorites.
If you suspect that in the future you may have more than one favorite, then the extra work may of course be worth it.
The design really depends on the relationships and whether or not there could be changes in the future to the possibility of different "favorite" relationships.