JPA:单向 OneToMany 的最佳实践

发布于 2024-11-11 14:43:00 字数 549 浏览 4 评论 0原文

我有几个关于 JPA 最佳实践(通过 hibernate)的小问题。

我的第一个问题是关于一个领域模型的复杂性。 我有一个模型帐户,它代表一个...帐户;) 帐户与其他对象有很多关系。其中很多需要由帐户对象知道,但其中一些只需要其他部分知道。

例如,我有一个消息模型,它表示发送到帐户的消息。 我真的不想用新的关系覆盖我的帐户模型,因为它已经有很多关系,所以我决定使帐户和模型之间的关系成为单向。

因此,我仅在 Message 类中而不是在 Account 类中将关系与 ManyToOne 关系进行映射。

您认为避免模型类中存在太多关系(在我的例子中是 Account )是一个很好的做法吗?或者您认为我必须将所有关系映射到我的帐户类中的帐户。那么,最佳实践是什么,单向关系还是双向关系?

我的第二个问题来自单向情况。当我删除帐户时,由于单向关系,引用该帐户的所有消息现在无法加载,因为父帐户丢失。

维护未损坏的数据库的最佳实践是什么? - 删除帐户时删除所有关系(就性能而言可能非常危险) - 进行一项工作,在此过程中逐步删除所有关系并停用帐户

感谢您的所有建议;)

I have several little questions about best practices with JPA (via hibernate).

My first question is about the complexity of one domain model.
I've got a model Account which represents an... account ;)
An account have a lot of relations with other objects. A lot of them need to be known by the Account object but some of them need to be known only for the other part.

For example, I've got a Message model which represents a message that is sent to an Account.
I don't really want to override my Account model with a new relation because it has already lot of relations, so I decide to make the relation between Account and Model unidirectional.

So, I've mapped the relation with a ManyToOne relation only in the Message class and not in Account.

Do you think it is a good practice just to avoid too much relations in a model class (Account in my case) ? Or do you think I must map ALL relations to an Account in my Account class. So, what's the best practice, unidirectional or bidirectional relations ?

My second question comes from the unidirectional case. When I remove an account, due to unidirectional relation, all messages refering this account now failed to load because the parent Account is missing.

What's the best practice to maintain a non corrupted database ?
- delete all relations when the account is deleted (can be very dangerous in term of performance)
- make a job which delete progressively all relations and deactivate the account during this process

Thank you for all suggestions ;)

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

扫码二维码加入Web技术交流群

发布评论

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

评论(1

看透却不说透 2024-11-18 14:43:00

如果您不需要从帐户导航到其消息(在代码或查询中),则可以毫无问题地使用单向关系。

无论您选择哪种解决方案,您都应该在消息与其帐户之间定义外键约束。这样,删除帐户而不先删除其消息将引发异常。这就是确保数据一致性不被破坏的方法。如果您希望能够删除帐户而不删除其消息,那么您应该首先将帐户的 ManyToOne 字段设置为 null,从而将该帐户与其消息分离。当然,关系必须标记为可选,并且外键列必须可为空。

但请注意,帐户与其消息之间存在关系(即使无法从代码的其余部分访问)将允许您

  • 在查询中使用此关系
  • ,并在该关系上设置级联删除,以便自动删除所有消息在删除帐户之前删除。

You may use unidirectional relationships without problem if you don't need to navigate from an account to its messages (in code or in queries).

whatever the solution you choose, you should define a foreign key constraint between the message and its account. This way, deleting an account without first deleting its messages will throw an exception. This is how you guarantee that the data coherence is not corrupted. If you want to be able to delete an account without deleting its messages, then you should first detach the account from its messages, by setting their account ManyToOne field to null. Of course, the relationship must be marked optional, and the forein key column must be nullable.

Note, though, that having a relationship from the account to its messages (even if it's not accessible from the rest of the code) would allow you to

  • use this relationship inside queries
  • set a cascade delete on the relationship, so that all messages are automatically deleted before an account is deleted.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文