1️⃣ What the relational model is (Codd)
The relational model describes data as:
- Relations (tables) → unordered sets of tuples (rows)
- Attributes → typed columns
- Primary keys → tuple identity
- Foreign keys → integrity between relations
- Declarative operations (relational algebra → SQL)
Key idea:
Data is independent of how it is accessed or stored
There is no navigation, only set-based queries.
2️⃣ What the object-oriented model is
The OO model represents the world as:
- Objects with identity
- Encapsulation (state + behavior)
- References / pointers
- Inheritance & polymorphism
- Graph navigation (
order.getCustomer().getAddress())
Key idea:
Data is accessed by navigating object graphs
3️⃣ Core differences (this is the heart)
| Aspect | Relational Model | Object-Oriented Model |
|---|---|---|
| Identity | Value-based (primary key) | Reference-based (object identity) |
| Structure | Flat relations | Object graphs |
| Access | Declarative (SQL) | Navigational |
| Duplication | Normalized, avoided | Common (denormalized fields) |
| Integrity | Enforced by DB | Enforced by code |
| Behavior | Data only | Data + behavior |
| Ordering | Unordered sets | Ordered collections |
4️⃣ The Object-Relational Impedance Mismatch
This mismatch is fundamental, not accidental.
Example
Order order = orderRepository.findById(id);
String city = order.getCustomer().getAddress().getCity();
This looks like one operation in OO.
But in relational terms:
orderscustomersaddresses
→ multiple joins, lazy loading, N+1 risks, transactions, caching issues.
Objects want graphs. Databases want sets.
5️⃣ Why this matters for backend developers
🔴 Performance traps
- N+1 queries
- Over-fetching / under-fetching
- Accidental Cartesian products
- LazyInitializationException
If you think OO only, you will:
- write slow code
- blame the database
- add caches instead of fixing queries
🔴 Transaction boundaries
- DB transactions operate on rows
- ORM sessions operate on object graphs
Mistake:
“I loaded the entity, why is it detached now?”
Correct thinking:
“The DB transaction ended, the object graph is no longer managed.”
🔴 Equality & identity bugs
entityA.equals(entityB)
- OO: reference vs logical equality
- DB: primary key identity
Classic bugs:
equals/hashCodebefore ID assigned- composite keys
- mutable keys in HashSet
🔴 Schema vs domain design
Bad approach:
“Let’s design entities first and generate schema.”
Better approach:
“Design the relational model first, then map a domain model on top.”
Why?
- DB is long-lived
- Code is disposable
- Schema mistakes are expensive
6️⃣ How senior engineers think about this
Senior backend engineers separate concerns:
- DB model → optimized for consistency, querying, constraints
- Domain model → optimized for behavior and use cases
- DTOs → optimized for API contracts
- ORM → mapping tool, not a magic layer
ORM is a convenience, not an abstraction leak-free layer
7️⃣ Interview-ready short answer (say this confidently)
“The relational model is set-based and declarative, focusing on data integrity and relations between values, while the object-oriented model is navigational and reference-based, focusing on behavior and object graphs.
This mismatch matters because ORMs can hide performance costs, transaction boundaries, and identity issues.
As a backend developer, you must think relationally when designing schemas and queries, and use OO models consciously on top — not assume they map naturally.”
8️⃣ Bonus: red flags interviewers listen for 🚩
If a candidate says:
- “Hibernate handles it”
- “The ORM will optimize it”
- “We don’t need foreign keys”
- “Objects map 1-to-1 to tables”
👉 That’s mid-level thinking.