The problem lies in neither relational databases nor OO programming, but in the conceptual difficulty mapping between the two logic models.
Both logical models are differently implementable using database servers, programming languages, design patterns, or other technologies.
Issues range from application to enterprise scale, whenever stored relational data is used in domain-driven object models, and vice versa.
Links are reversible (INNER JOIN is symmetric to follow foreign keys backwards), forming undirected graphs.
In order for an ORM to work properly, tables that are linked via Foreign Key/Primary Key relations need to be mapped to associations in object-oriented analysis.
[citation needed] Relational's unit is the transaction which outsizes any OO class methods.
Transactions include arbitrary data manipulation combinations, while OO only has individual assignments to primitive fields.
Mainly framework support compensates, by automating data manipulation and presentation patterns on the level of modelling.
Although object-relational impedance mismatches can occur with object-oriented programming in general, a particular area of difficulty is with object–relational mappers (ORMs).
Date says a true relational DBMS overcomes the problem,[6][7][8] as domains and classes are equivalent.
Productive UIs should prevent illegal transactions (database constraint violations) to help operators and other non-programmers manage the data.
This requires knowledge about database attributes beyond name and type, which duplicates logic in the relational schemata.
Frameworks leverage referential integrity constraints and other schema information to standardize handling away from case-by-case code.
OO code (Java and .NET respectively) extend them and are invokeable in SQL as fluently as if built into the DBMS.
OO is in the backend because SQL will never get modern libraries and structures for today's programmers, despite the ISO SQL-99 committee wanting to add procedural.
This blurs the division of responsibility between "application programming" and "database administration" because implementing constraints and triggers now requires both DBA and OO skills.
OO in the backend encourages bad architecture as business logic should not be in the data tier.
Relational says the DBMS is authoritative and the OO program's objects are temporary copies (possibly outdated if the database is modified concurrently).