Talk:Object–relational impedance mismatch

message: 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)
thread_title:   Data Independence  

message: "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)
replies: text: - I rewrote the paragraph. --M4gnum0n (talk) 12:51, 27 May 2015 (UTC)
thread_title: dumb sentence

message: (inserted for readability Rursus dixit. (mbork3!) 07:52, 9 April 2010 (UTC)
replies: text: 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)

text: - tagged the whole section as there were more. --M4gnum0n (talk) 13:06, 27 May 2015 (UTC)
thread_title: (random heading)

message: 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)
replies: text:  - entry deleted. --M4gnum0n (talk) 13:04, 27 May 2015 (UTC)
thread_title: Uniqueness Observation

message: 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)
thread_title: Term authorship

message: 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)
replies: text: 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. (mbork3!) 07:59, 9 April 2010 (UTC)
thread_title: NPOV problems?

message: 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)
replies: text: 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)
thread_title: Generally bad article

message: 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)
thread_title: A little less technical?

message: 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)
thread_title:  Sentence fragment 

message: We need a rewrite  — Preceding unsigned comment added by 71.14.78.88 (talk) 13:50, 24 October 2014 (UTC)
thread_title:  Doesn't read like a wikipedia article 

message: 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.C. J. Date, Relational Database Writings
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 . 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)
thread_title:  Reference for: Limitations of OO principles as a basis for a data model 

message: 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)
thread_title:  Schema Bound might have incorrect sentence? 

message: 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)
thread_title:  Inability to put methods into DB fields 

message: 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)
thread_title:  Missing a reference to the Repository patter 

message: 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)
thread_title:  Contention Section Too Long 

message: @inam Nkumanda 41.114.249.204 (talk) 15:12, 21 March 2023 (UTC)
thread_title:  Constraints to 

message: 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)
thread_title:  Shortened the article