Content deleted Content added
Daniel.z.tg (talk | contribs) m Grammar |
No edit summary |
||
| (23 intermediate revisions by 18 users not shown) | |||
Line 1:
{{short description|Set of conceptual and technical difficulties}}
{{More footnotes|date=August 2020}}
'''Object–relational impedance mismatch'''
The term ''
== Mismatches ==
Line 17:
==== Interface, class, inheritance and polymorphism ====
Objects must implement [[Interface (computer science)|interfaces]] to not expose internals. Relational uses [[View (database)|views]] to vary perspectives and constraints. It lacks OO concepts like [[class (computer science)|classes]], [[Inheritance (object-oriented programming)|inheritance]] and [[polymorphism (computer science)|polymorphism]].
==== Mapping to relational concepts ====
=== Data type differences ===
Relational prohibits by-reference (e.g. [[pointer (computer programming)|pointers]]), while OO embraces by-reference. [[Scalar (computing)|Scalar types]] differ between them, impeding mapping.
[[SQL]] supports [[String (computer science)|string]]s with maximum lengths (faster than without) and [[collation]]s. OO has collation only with [[Sorting algorithm|sort routines]] and strings limited only by memory. SQL usually ignores trailing [[Whitespace (computer science)|whitespace]] during comparison [[SQL syntax#Data types|char]], but OO libraries do not. OO does not newtype using constraints on primitives.
=== Structural and integrity differences ===
Line 42:
=== Alternative architectures ===
# ''NoSQL''. The mismatch is not between OO and DBMSes. Object-relational impedance mismatch is eponymously only between OO and '''R'''DBMSes. Alternatives like [[NoSQL]] or [[XML database]]s avoid this.
# ''Functional-relational mapping''. [[List_comprehension|Comprehensions]] in functional programming languages are isomorphic with relational queries.<ref>{{cite web | url=https://nbviewer.org/github/phelps-sg/python-bigdata/blob/master/src/main/ipynb/relational-python.ipynb | title=Jupyter Notebook Viewer }}</ref> Some functional programming languages implement functional-relational mapping.<ref>{{cite web | url=https://scala-slick.org/doc/stable/introduction.html | title=Introduction · Slick }}</ref> The direct correspondence between comprehensions and queries avoids many of the problems of object-relational mapping.
=== Minimization in OO ===
Line 51 ⟶ 53:
==== Advantages ====
* Straightforward to frameworks and automation around data transport, presentation, and validation
* Smaller, faster, quicker code{{Citation needed|date=July 2024}}
* Dynamic [[database schema]]
* Namespace and semantic match
Line 66 ⟶ 68:
== Occurrence ==
Although object-relational impedance mismatches can occur with object-oriented programming in general, a particular area of difficulty is with [[
== Contention ==
=== True RDBMS
[[Christopher J. Date]] says a true [[relational DBMS]] overcomes the problem,<ref>{{Citation|url=http://dbdebunk.blogspot.com.br/2012/08/type-vs-___domain-and-class.html|first1=Christopher ‘Chris’ J|last1=Date|first2=Fabian|last2=Pascal|author2-link=Fabian Pascal|title=Database debunkings|date=2012-08-12|orig-year=2005|contribution=Type vs. Domain and Class|publisher=Google|format=World Wide Web log|access-date=12 September 2012}}.</ref><ref>{{Citation|first=Christopher ‘Chris’ J|last=Date|author-mask=3|chapter=4. On the notion of logical difference|quote=Class seems to be indistinguishable from type, as that term is classically understood|page=39|title=Date on Database: writings 2000–2006|publisher=Apress|year=2006|place=[[United States of America|USA]]|isbn=978-1-59059-746-0|series=The expert’s voice in database; Relational database select writings}}.</ref><ref>{{Citation|first=Christopher ‘Chris’ J|last=Date|author-mask=3|chapter=26. Object/Relational databases|quote=...any such ''rapprochement'' should be firmly based on the relational model|page=[https://archive.org/details/introductiontoda0000date/page/859 859]|title=An introduction to database systems|edition=8th|publisher=Pearson Addison Wesley|year=2004|isbn=978-0-321-19784-9|chapter-url=https://archive.org/details/introductiontoda0000date/page/859}}.</ref> as [[data ___domain|domains]] and [[class (computer science)|classes]] are equivalent. Mapping between relational and OO is a mistake.<ref>{{Citation|last1=Date|first1=Christopher ‘Chris’ J|author1-link=
=== Constraints and
[[Domain object]]s and [[user interface]]s have mismatched impedances. Productive UIs should prevent illegal transactions
Frameworks leverage referential integrity constraints and other schema information to standardize handling away from case-by-case code.
=== SQL-
[[SQL]], lacking ___domain types, impedes OO modelling.{{Disputed inline|date=September 2024}} 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.
Line 87 ⟶ 89:
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.
=== Location of
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.
=== Division of
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.
Line 98 ⟶ 100:
Key philosophical differences exist:
* '''Declarative vs. imperative interfaces'''{{snd}} Relational uses declarative data while OO uses imperative behavior. Few compensate for relational with triggers and stored procedures.
* '''Schema bound'''{{snd}} Relational limits rows to their entity schemas. OO's inheritance (tree or not) is similar. OO can also add attributes. New and few dynamic database systems unlimit this for relational.
* '''Access rules'''{{snd}} Relational uses standardized operators, while OO classes have individual methods. OO is more expressive, but relational has math-like reasoning, integrity, and design consistency.
* '''Relationship between nouns and verbs'''{{snd}} An OO [[class (computer science)|class]] is a noun entity tightly associated with verb actions. This forms a [[Conceptual model (computer science)|concept]]. Relational disputes the naturalness or logicality of that tight association.
* '''Object identity'''{{snd}} Two mutable objects with the same state differ. Relational ignores this uniqueness, and must fabricate it with [[candidate key]]s but that is a poor practice unless this identifier exists in the real world. Identity is permanent in relational, but maybe transient in OO.
* '''Normalization'''{{snd}} OO neglects [[Database normalization|relational normalization]]. However, objects interlinked via [[Pointer (computer programming)|pointers]] are arguably a [[network database]], which is arguably
* '''Schema inheritance'''{{snd}} Relational schemas reject OO's hierarchical inheritance. Relational accepts more powerful [[set theory]]. Unpopular non-tree (non-[[Java (language)|Java]]) OO exists, but is harder than relational algebra.
* '''Structure vs. behaviour'''{{snd}} OO focuses on structure (maintainability, extensibility, reusable, safe). Relational focuses on behavior (efficiency, adaptability, fault-tolerance, liveness, logical integrity, etc.). OO code serves programmers, while relational stresses user-visible behavior. However it could be non-inherent in relational, as task-specific views commonly present information to subtasks, but IDEs ignore this and assume objects are used.
Line 125 ⟶ 127:
{{DEFAULTSORT:Object-relational impedance mismatch}}
[[Category:Object-oriented programming]]
[[Category:
[[Category:Relational model]]
| |||