Content deleted Content added
Daniel.z.tg (talk | contribs) Already fixed issues |
No edit summary |
||
| (25 intermediate revisions by 19 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
==== 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 36:
=== Transactional differences ===
Relational's unit is the [[database transaction|transaction]] which outsizes any OO class methods. Transactions include arbitrary data
== Solving impedance mismatch ==
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 ===
[[Object database]]s (OODBMS) to avoid the mismatch exist but only less successfully than relational databases. OO is a poor basis for schemas.<ref>C. J. Date, Relational Database Writings</ref> Future OO database research involves [[Software transactional memory|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)
==== 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.
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.
=== 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
* '''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
* '''Object identity'''{{snd}} Two mutable objects with the same state differ. Relational ignores this uniqueness, and must fabricate it with [[candidate key]]s but
* '''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
* '''Set vs. graph relationships'''{{snd}} Relational follows [[set theory]], but OO follows [[graph theory]]. While equivalent, access and management paradigms differ.
Therefore, partisans argue
ORMs situationally offer advantages. Skeptics cite
== See also ==
Line 125 ⟶ 127:
{{DEFAULTSORT:Object-relational impedance mismatch}}
[[Category:Object-oriented programming]]
[[Category:
[[Category:Relational model]]
| |||