Entity Relationships, Fetch Plans, and N+1 Queries

Lesson roadmap: Start with the mental model, then follow the design choices, common pitfalls, and the practical workflow you should apply in a real project.

Entity relationships mirror data relationships: Orders have items, users have profiles, departments have employees.

Owning side and join column details matter: The mapping is not just decoration; it defines how the ORM writes and reads relationships.

Lazy vs eager loading changes runtime behavior: Fetching too much data hurts performance, but fetching too little at the wrong time can cause extra queries or missing-session issues.

Advanced habit: Treat relationship mapping and fetch behavior as part of performance design, not only as annotations to “make it work.”

Relationship mapping is design work: The annotations are small, but the choices behind them affect query count, transaction behavior, serialization, and how easy the domain model is to reason about.

Owning side matters: In bidirectional relationships, one side is responsible for updating the foreign-key relationship in the database. If you do not know which side owns the mapping, updates become confusing fast.

Lazy vs eager: Lazy loading keeps initial queries smaller but may trigger additional queries later. Eager loading can simplify some reads but may load more data than the use case needs.

N+1 warning: Loading a list of parent entities and then touching a lazily loaded child collection for each one can silently explode the number of queries. Advanced persistence work includes thinking about fetch plans, joins, and data shape deliberately.

How to study this module: Keep a simple domain in mind, such as users, orders, or tasks. It is easier to understand JDBC, transactions, and ORM mapping when every SQL statement serves a clear business action.

Code review mindset: Database code is not only about “does it work.” Reviewers also look for resource safety, transaction boundaries, predictable query counts, and whether the persistence layer leaks too much SQL detail into higher layers.

Production habit: Measure query behavior early. Slow queries, long transactions, and leaked connections usually hurt real systems more than syntax mistakes do.