x-follows-y 场景的实体关系建模

发布于 2024-11-28 21:58:22 字数 262 浏览 4 评论 0原文

假设有两个模型：User 和 Question。我可以使用 @OneToMany 来指示一个用户可以有多个问题。现在，如果我想允许用户关注一个或多个问题，我是否应该构建一个具有两个属性（用户和问题）的Follow模型？或者只是将属性添加到 User 模型中以获取后续问题列表？哪一个更好？这种场景的一般设计原则是什么？考虑到后端数据库操作，上面哪种方法会更有效？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

提笔书几行 2024-12-05 21:58:22

这里的关键思想是，一个问题只有一个提问者，但有多个追随者。在数据模型中，您将所有内容设想为表格，您将进行如下设计：

USER (id(PK), name, ...)
QUESTION (id(PK), title, text, author(FK to USER))
FOLLOW (userid(FK to USER), questionid (FK to QUESTION))

因为作者关系是从 USER 到 QUESTION 的一对多关系，以及 USER 和 QUESTION 之间的多对多关系。 FOLLOW 表是通常的连接表。

现在使用 JPA 进行 ORM 是事情变得有趣的地方。是的，您可以通过存储每个用户的问题列表来避免显式构建 Follow 类。您将需要 @ManyToMany 和 @JoinTable。这是否比显式的 Follow 类（可能带有两个 @ManyToOne 或两个 @OneToMany ）更有效？我不太确定，但我怀疑，由于 JPA 只是一个规范，并且可以有多种实现，因此不同的实现可能在性能方面有所不同。当然，您可以尝试两种方法，编写一些查询，然后查看生成的 SQL。如果您已经了解高效获取策略的技术，并且具有避免 n+1 选择问题等其他技能，那么您可能会发现这是一个有趣的练习。

当然，避免连接表的模型类更符合 ORM 风格，因为您可以只关注对象级别，而不必过多担心底层表。但了解幕后发生的事情是有好处的，因为您仍然需要了解如何进行有效的获取以及如何避免 n+1 选择等。

此外，如果您的关注关系有自己的属性，您可能会发现明确的Follow模型类是一个好主意。

底线是直接的多对多，没有 Follow 模型可能是最干净的，但是选择对您来说最易读的模型，如果您有任何疑问，请进行一些分析。我确实相信最终只查看生成的 SQL 就能告诉您想要知道的信息，因为 JPA 没有指定 SQL。 JPA 实现也可能非常智能。

The key idea here is that a question has a single asker but multiple followers. Working at the data model, where you envision everything as tables, you would design as follows:

USER (id(PK), name, ...)
QUESTION (id(PK), title, text, author(FK to USER))
FOLLOW (userid(FK to USER), questionid (FK to QUESTION))

Because the author relation is one-to-many from USER to QUESTION and many-to-many between USER and QUESTION. The FOLLOW table is the usual join table.

Now doing the ORM with JPA is where things get interesting. Yes, you can avoid building a Follow class explicitly by storing a list of questions for each user. You will need @ManyToMany and @JoinTable. Is this more efficient than an explicit Follow class, perhaps with two @ManyToOnes or two @OneToManys? I'm not really sure, but I would suspect that since JPA is just a specification and there can be multiple implementations, that perhaps different implementations can, well, differ in how performant they are. You can of course try things both ways, write up some queries, and look at the generated SQL. If you are already aware of techniques for efficient fetch strategies, and have other skills like avoiding the n+1 select problem, then you may find this a fun exercise.

Certainly, avoiding a model class for a join table is more ORM-ish since you can just focus on the object level and not worry too much about the underlying tables. But it is good to know what goes on behind the scenes as you still need to understand how to do efficient fetching and how to avoid n+1 selects, etc.

Also, if your follow relation has attributes of its own, you may find the explicit Follow model class is a good idea.

Bottom line is a straight many-to-many without the Follow model is probably the cleanest, but choose what is most readable for you, and do some profiling if you have any doubts. I do believe that ultimately only looking at the generated SQL will tell you what you want to know, because JPA does not specify the SQL. And JPA implementations might be pretty smart, too.

回复收藏 0 原文

~没有更多了~