@OneToMany
コレクション値の関連付けで「非常に多く」の側との関係を使用する価値はありますか?
、またはのようList<OrderLine>
に、インスタンスがほとんどない場合、または厳密な論理関係がある場合、それを行うことは明らかです。しかし、 や のように多くのインスタンスを保持する場合、orのような単純な操作では、要素のコレクション全体を永続化コンテキストで管理する必要があります。高すぎませんか?または、これらの場合、双方向の関係を避ける必要がありますか?Order
Set<Phone>
Person
Set<Order>
Customer
List<Event>
Company
Order#setCustomer()
Event#setCompany()
必然的な部分は、これらの関係のカスケード設定です。/ のマージ/永続化機能をその「子」にカスケードすることは論理的Customer
ですCompany
が、最終的にリソースの無駄にはなりませんか?
最後になりましたが、カスケードの削除です。明らかに、4 つの関係すべてに完全に適合します。しかし、単一値の関連付けの一方向の関係が残っている場合は、親が削除されたときにクエリを使用して子を個別に削除する必要がありますか?
現在、アイテムの数が非常に少なく、エンティティ間に明確な親子関係がある場合にのみ、双方向の関係を使用しています。ほとんどのジョブは、単一値の終わり ( Order
/Entity
を単独で削除する) と、親が削除されると ( Customer
/を削除すると) クエリを介して実行されますCompany
。
JPA に関する本を何冊か読み直した後、Java EE アプリケーションで持続性を使用する正しい方法に従っていないのではないかと思い始めました。
一般に、Java EE アプリケーションでコレクション内の多くのインスタンスと双方向の関係を使用することについてどう思いますか? また、特に単方向の関係を選択した場合、カスケードをどのように管理しますか?