Talk:Object–relational impedance mismatch

Data Independence

The article has no discussion of the concept of "Data Independence" in particular, and of Relational Data Concepts in general. Data Independence is a fundamental concept in the development of the state of the art in databases, dating back to Codd's published paper in 1970. Data Independence is as important for preventing the so-called "ripple effect" as encapsulation is in an Object Oriented world.

For better or for worse, the concepts of relational data modeling have been developed for over 40 years in the context of databases and database management systems. This adds yet one more layer of obscurity to the mismatch between Relational and OO as seen from both sides of the fence. Almost all of OO has been developed from the point of view of a "process centric" view of the universe, one in which persistent shared data is merely a subsystem of the processing environment. This is a progammer's wotld view, and not the world view of a strategic data manager. To be fair, OO unified the "process centric" and the "data centric" world views in ways that more traditional programming paradigms did not. Some relational enthusiasts fail to see this, or fail to accept it as a step forward.

OO enthusiasts equally fail to see the way in which the relational model represented a quantum leap forward in the state of the art. Sometimes, OO structures reimpose the graph model of data onto the world they rule. The benefits of the relational model over the graph model are almost entirely obscured.

Joe Thursday (talk) 15:49, 11 March 2011 (UTC)[reply]

dumb sentence

"schema modifications that might serve no purpose beyond making a programmer's life modestly easier would be vetoed if they result in unacceptable design decisions such as denormalization of transactional schemas."

Isn't that a ridiculously obvious statement? I feel dumber after having read it. 24.129.77.95 (talk) 21:19, 11 May 2010 (UTC)Ryan[reply]

Done - I rewrote the paragraph. --M4gnum0n (talk) 12:51, 27 May 2015 (UTC)[reply]

(random heading)

(inserted for readability Rursus dixit. (^mbork³!) 07:52, 9 April 2010 (UTC))[reply]

This page has much interesting information, but fundamentally flawed by the mix-up between SQL and relational. I have thus renamed it and changed most mentions of relational to SQL, but it really should be split between what are specifically SQL problems and what are OO misunderstandings of the relational model in particular or database administration in general.

OO is poorly defined, or at least consistently defined. It is hard not to have a misunderstanding of something that is poorly defined. It seems everybody's psychology about OOP is different from each other. Further, I believe that domain types and relational are or should be orthogonal. As long as domain types follow conventions that relational expects, there is no reason for tight integration between the two. If you marry the two, then you risk favoring some domains at the expense of others when choosing relational. Also, which are problems specific to SQL but not relational in general?

Nulls for one thing; repeated rows in the results for another. Read the many essays of Date (who worked with Codd to create the relational model) for more on why SQL is a bad implementation of the relational model. -- Derek Ross | Talk 05:08, 17 August 2006 (UTC)[reply]

"It has been argued that trying to inherit from a database record is a mistake." - This seems to me to be typical 'weasel words'. See http://en.wikipedia.org/wiki/Wikipedia:Avoid_weasel_words .

Done - tagged the whole section as there were more. --M4gnum0n (talk) 13:06, 27 May 2015 (UTC)[reply]

Uniqueness Observation

Uniqueness Observation — Row identities (keys) generally have a text-representable form, but objects don't require an externally-viewable unique identifier.

Externally-viewable they may not be, but unique identifiers are always present internally (e.g., pointers, reference values). They must be valid at least during execution, when OO is actually in effect. Doesn't that count? Cheers. --189.25.93.26 19:47, 2 July 2007 (UTC)[reply]

Done - entry deleted. --M4gnum0n (talk) 13:04, 27 May 2015 (UTC)[reply]

Allegedly

The fourth paragraph starts as follows: Access to objects in object-oriented programs is allegedly best performed via interfaces.... This is wrong use of the word allegedly, because that word implies that the statement is actually not true (as in he allegedly committed a murder, then they think he did, but in fact he did not), while from context it seems the intended meaning is something like probably, usually, generally or according to most textbooks. But since I was reading this to try to learn something, I am not savvy enough on the subject to make good changes myself. Please help out :) Dtuinhof (talk) 09:09, 14 March 2008 (UTC) Dtuinhof (talk) 09:09, 14 March 2008 (UTC)[reply]

The boundary between "interface" and "implementation" is often fuzzy. For example, some will talk about "hiding the fact that the output will be HTML because HTML is an implementation." That is not entirely true. A web browser provides the "implementation" of HTML; and to it, HTML is merely an interface; an abstract description of a document. A relational table is sometimes called an "implementation" even though the actual implementation (not seen by the user) may be disk pointers and bits. It's thus a sticky philosophical area. It's often relative to a tool's perspective. [This unsigned contribution added on 14:11, 9 September 2009‎ by 66.120.226.82 (talk)‎ ]

This is wrong use of the word allegedly, because that word implies that the statement is actually not true

You misunderstand the meaning of the word allegedly. Doesn't have to be false, just means someone thinks it's true, whether it is or not.

Allegedly, the sun will come up tomorrow. = "Someone said the sun will come up tomorrow." Mathglot (talk) 01:47, 17 February 2012 (UTC)[reply]

Dtuinhof is absolutely correct about the connotation of the word "allegedly" however. I read the article and thought the same thing: Ah, looks like someone had a bone to pick with OOP while writing this. It's a weasel word and should be removed. As such, I'm going to do so. --134.74.17.96 (talk) 22:06, 25 June 2012 (UTC)[reply]

Term authorship

Who coined the term object-relational impedance mismatch? The article doesn't clarify that. —Preceding unsigned comment added by Pmerson (talk • contribs) 23:32, 17 November 2008 (UTC)[reply]

NPOV problems?

The article right now really reads like it was written by an OOP advocate. For example, the following quote: "In particular, object-oriented modeling emphasizes the essential concept of an invariant, which requires the use of encapsulation before any access to data of OOP objects is performed. These invariants cannot be represented in relational databases."

I would say that in relational modeling, in fact, constraints are declarations of invariants that the data must respect (and that therefore, the RDBMS must enforce). The RDBMS doesn't "hide" information in the way that OOP private fields do, but that doesn't mean it provides the clients unrestricted power to mess with the attributes of a tuple; all updates must satisfy whatever constraints are relevant. So, the integrity of the data is not enforced by forbidding clients from accessing fields directly, but rather by explicit definition of the valid states of the data. 63.80.102.4 (talk) 19:37, 17 April 2009 (UTC)[reply]

Agreed, except the NPOV is minor and prob due to an OOP oriented person writing the clause, and it is a good start for writing an "opposite" paragraph turning the coin to the RDB perspective. Rursus dixit. (^mbork³!) 07:59, 9 April 2010 (UTC)[reply]

Generally bad article

Somewhat connected to the idea that this article lacks NPOV, most of the points in this article seem to be instances of an OO programmer manufacturing superfluous complaints out of obvious differences between the data-handling methods and expectations of a programming paradigm on the one hand, and the data-handling capabilities of a database management architecture on the other hand. It's kind of ridiculous. It's like complaining that a tree is not like a bus. Of course an RDBMS doesn't do well what an OOL does well--they were never designed to!

Once one understands how an RDBMS should be used, it's easy to then use it for data storage from within your application, whether OO or not. I've done it (and so have lots of people)!

This whole article needs to be completely rewritten. Metafax1 (talk) 10:08, 30 August 2010 (UTC)[reply]

This topic is so contentious and so early in the stages of exploration and research that it will probably be impossible to satisfy everybody. Two paradigms are essentially "colliding", trying to work out how to divide up their roles and specialties effectively without taking away from the best of each. (Anonymous) — Preceding unsigned comment added by 146.233.255.201 (talk) 19:42, 26 August 2011 (UTC)[reply]

I am mostly concerned about link to “How Vietnam Can Still Be Won” ... whereas the parent article is genuinely scholarly-like article on issue with OR/M technology, the latter is mostly (self-?)advertising heavily criticized in its comments as valueless. I am not sure how to find out who changed particular line of text, but I wouldn’t be surprised if the link was added by the author of that article. Ceplm (talk) 10:05, 5 December 2011 (UTC)[reply]

A little less technical?

One of the main purposes of using an OOP language is to locate a set of data fields with a set of functions and encapsulate those in an object. Translated, this means that data and programs are defined together. One of the main purposes of an RDMS is to separate the data from the programming code. Translated, this means that data and programs are separate by design.

By this definition, a single system could not be both Object Oriented and Relational at the same time.

The problem with the above argument is that thousands of programmers actually use OOP programs and a RDMS in a single project. The difference is that the systems they create are not a single system but at least two systems that communicate over a standard interface called SQL. So these systems aren’t relational or object oriented but like gravel, a mix of at least two quite different things. Add triggers to define the intimate relations between tables in the RDMS and you end up with different languages and different functions to create your system.

Just like a physical set of objects, a row in a table or list can only be in one physical order at a time. However, using indexes, we can make it appear that the same data in a table or list is in multiple orders at the same time. I suggest that it is not only possible but also practical to have a real OOP system that also looks like a RDMS. If the OOP system implemented SQL so that the tables and relationships that are manipulated were in fact object oriented things instead of relational things then a single system could actually be both at the same time even though my original argument says that is impossible. The axiom that says “if it walks like a duck and smells like a duck then you can assume it is a duck (even if it isn’t)”, works in this situation.

Most of the incompatibilities between Relational and Object Oriented come from the fact that the DBMS and the OOP code are created by different companies with different types, functions and methodology. If one system could act as both, then almost all of those differences would go away. (Types would be the same. Expression evaluation would be the same. Functions and variables would be the same.) Properties of Relational Databases such as security, efficient execution, transactions, relational integrity and triggers could all be handled with OOP code. The advantage of accessing data with a standard, high level interface like SQL would give the OOP system the advantages of the RDMS while retaining the advantages of encapsulating data with the functions that act on that data. It is possible to have your cake and eat it too.

The idea that programming should be separated from the data it works on is simply wrong. The popularity of Relational Databases was the result of them being a better solution than the alternatives, not necessarily an optimal solution. The RDMS gave you a multi-user, standardized data repository. The RDMS gave a single place to look for a table. Data access could be optimized in the DBMS without changing the programs, as the access to the data was through SQL. With database schema and triggers, you could make sure that tables had referential integrity and in some cases implement real time posting of transactions with centralized data checking. SQL queries replaced custom queries which resulted in more standardized and readable queries but at the expense of computational speed which has become increasingly less important. The OOP model mandates that code that changes or manipulates the data of an object must be closely defined to that class which is even better than using an RDMS because the database isn’t the only repository of all code and data for a single entity. All of the above advantages of using a RDMS can be had in a properly designed OOP system. RDMS’s filled a need over the last 20 years but will be supplanted by newer systems that have all the advantages of a RDMS but without the separation of data and code.

Clarkd99 (talk) 16:50, 3 July 2012 (UTC)[reply]

Sentence fragment

The first bit of words in the second paragraphin the section Contention reads "The impedance mismatch in programming between the domain objects and the user interface." This sentence fragment has no verb. I can't figure out what is meant by this. Can someone who knows more about this than I put in the appropriate verb? Should it read "The impedance mismatch in programming is between the domain objects and the user interface."? David s graff (talk) 16:05, 28 May 2013 (UTC)[reply]

Doesn't read like a wikipedia article

We need a rewrite — Preceding unsigned comment added by 71.14.78.88 (talk) 13:50, 24 October 2014 (UTC)[reply]

Reference for: Limitations of OO principles as a basis for a data model

The article contains this sentence with a generic reference to Date's Relational Database Writings:

limitations of OO principles as a basis for a data model.<ref>C. J. Date, Relational Database Writings</ref>

To my knowledge, these Relational Database Writings are a series of at least 5 books, spanning over almost three decades. Could the reference please be more precise, referencing at least the specific book, preferably even the chapter?

- It seems volume 4 deals with the question [1]. Snapshot not enough for the guarantee of strong references, but the book review meanwhile will be leading you to: this. --Askedonty (talk) 13:40, 25 November 2017 (UTC)[reply]

Schema Bound might have incorrect sentence?

It says a table row must confirm to the entity (so the table definition), but an object must confirm in the same way to the class definition. I feel like the wrong two concepts are being compared. Snorkop (talk) 20:44, 15 September 2021 (UTC)[reply]

Inability to put methods into DB fields

Is the inability to put methods, except as code-text literals, into ORDBs considered an example of the Data Type mismatch? If so, perhaps that should be included/highlighted in that section: it was the first seemingly-intrinsic failure of ORM that occurred to me when reading the Wikipedia Article on ORM. (I am far from an expert on ORDB's so if I'm mistaken that this is an issue, please forgive and let me know.)

OlyDLG (talk) 22:19, 16 May 2022 (UTC)[reply]

Missing a reference to the Repository patter

I am missing a reference to the Repository pattern here. IMO, the pattern is one that significantly helps to decouple database schema from application data structure. Ztyx (talk) 15:22, 20 February 2023 (UTC)[reply]

Contention Section Too Long

The Contention section late in the article is massive, and contains numerous topics: as well as many, many weasel words. A first step towards fixing this article is sub-sectioning this section into manageable smaller pieces: and then modifying, deleting, or rearranging them. (Some should go in entirely different sections of the article, in my opinion.) — Preceding unsigned comment added by Ronoth (talk • contribs) 22:24, 7 March 2023 (UTC)[reply]

Constraints to

@inam Nkumanda 41.114.249.204 (talk) 15:12, 21 March 2023 (UTC)[reply]

Shortened the article

I greatly shortened the article to solve the "too long" problem. I removed all the weasel words to focus on the main points. Now it reads like a Wikipedia article and not a personal essay. Feel free to correct any oversimplifications. This shortening should have reduced NPOV problems, but go ahead if extra words are needed. The goal was not a rewrite, but it may read like a rewrite and solve the problems a rewrite was requested for. Daniel.z.tg (talk) 04:20, 19 August 2023 (UTC)[reply]

“SQL Lacks Domain Types”

The subsection “SQL-specific impedance and workarounds” states that “SQL, lacking domain types, impedes OO modelling.”

This is facially incorrect and should be revised or at least explained. For example see ISO/IEC 9075-2:1999 Section 4.14 (discussing “A domain definition specifies a data type.”).

Greencactus22 (talk) 01:53, 18 September 2024 (UTC)[reply]