Object–relational impedance mismatch

Object encapsulation hides internals. Object properties only show through implemented interfaces. However, many ORMs expose the properties publicly to work with database columns. Metaprogramming ORMs avoid violating encapsulation.

"Private" versus "public" is need-based in relational. In OO it is absolutely class-based. This relativity versus absolutism of classifications and characteristics clashes.

Objects must implement interfaces to expose internals. Relational uses views to vary perspectives and constraints. It lacks OO concepts like classes, inheritance and polymorphism.

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.

Relational prohibits by-reference (e.g. pointers), while OO embraces by-reference. Scalar types differ between them, impeding mapping.

SQL supports strings with maximum lengths (faster than without) and collations. OO has collation only with sort routines and strings limited only by memory. SQL usually ignores trailing whitespace during comparison, but OO libraries do not. OO does not newtype using constraints on primitives.

Objects can comprise other objects or specialize. Relational is unnested, and a relation (tuples with the same header) does not fit in OO.

Relational uses declarative constraints on scalar types, attributes, relation variables, and/or globally. OO uses exceptions protecting object internals.

Relational uses standardized operators for data manipulation, while OO uses per-class per-case imperative. Any OO declarative support is for lists and hash tables, distinct from the sets in relational.

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. OO lacks isolation and durability, so atomicity and consistency are only with primitives.

The mismatch is not between OO and DBMSes. Object-relational impedance mismatch is eponymously only between OO and RDBMSes. Alternatives like NoSQL or XML databases avoid this.

Object databases (OODBMS) to avoid the mismatch exist but only less successfully than relational databases. OO is a poor basis for schemas.[2] Future OO database research involves transactional memory.

Another solution layers the domain and framework logic. Here, OO maps relational aspects at runtime rather than statically. Frameworks have a tuple class (also named row or entity) and a relation class (a.k.a dataset).

• Straightforward to frameworks and automation around data transport, presentation, and validation
• Smaller, faster, quicker code
• Dynamic database schema
• Namespace and semantic match
• Expressive constraints
• Avoids complex mapping

• No static typing. Typed accessors mitigate this.
• Indirection performance cost
• Ignores concepts like polymorphism

Mixing OO levels of discourse is problematic. Mainly framework support compensates, by automating data manipulation and presentation patterns on the level of modelling. Reflection and code generation are used. Reflection addresses code as data to allow automatic data transport, presentation, and integrity. Generation turns schemas into classes and helpers. Both have anomalies between levels, where generated classes have both domain properties (e.g. Name, Address, Phone) and framework properties (e.g. IsModified).

Christopher J. Date says a true relational DBMS overcomes the problem,[4][5][6] as domains and classes are equivalent. Mapping between relational and OO is a mistake.[7] Relational tuples relate, not represent, entities. OO's role becomes only managing fields.

Domain objects and user interfaces have mismatched impedances. 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.

SQL, lacking domain types, impedes OO modelling. It is lossy between the DBMS and the application (OO or not). However, many avoid NoSQL and alternative vendor-specific query languages. DBMSes also ignore Business System 12 and Tutorial D.

Mainstream DBMSes like Oracle and Microsoft SQL Server solve this. OO code (Java and .NET respectively) extend them and are invokeable in SQL as fluently as if built into the DBMS. Reusing library routines across multiple schemas is a supported modern paradigm.

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. It is reasonable to use them directly rather than changing SQL. This blurs the division of responsibility between "application programming" and "database administration" because implementing constraints and triggers now requires both DBA and OO skills.

This contention may be moot. RDBMSes are not for modelling. SQL is only lossy when abused for modelling. SQL is for querying, sorting, filtering, and storing big data. 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). OO says the objects are authoritative, and the DBMS is just for persistence.

New features change both code and schemas. The schema is the DBA's responsibility. DBAs are responsible for reliability, so they refuse programmers' unnecessary modifications. Staging databases help but merely move the approval to release time. DBAs want to contain changes to code, where defects are less catastrophic.

More collaboration solves this. Schema change decisions should be from business needs. Novel data or performance boosts both modify the schema.