Talk:Object–relational mapping

Introduction

"This creates, in effect, a "virtual object database" that can be used from within the programming language." I don't think this is the only way for ORM mechanisms/frameworks/tools. Instead, I will say that this is a common implementation for ORM solutions. "Mapping" as relating objects to rows could be solved by creating "hybrid" objects (objects with PK or FK attributes), but also with a real external mapping without changing or mixing domain classes with records. 63.128.77.30 (talk) 17:00, 16 March 2015 (UTC)

"technique for converting data between incompatible type systems" sounds like a contradiction in terms. Compatible means two types are able to be converted between, so if they're incompatible, you can't convert between them. — Preceding unsigned comment added by 2601:283:4A80:5300:A40A:B4F:1584:3532 (talk) 20:19, 5 April 2022 (UTC)

I updated the summary today to try and address some of these concerns. I think the name of the technique gives a solid foundation for an encyclopedic article to explain what these tools do: they map objects to relations. Also, while the title doesn't imply this, in practice with "ORM" people mean that the objects are in a heap, and the relations are in a database. So for a first layer of definition, ORM is automated mapping of objects in a heap, to relations in a database. Then, as a second layer of detail, I listed out the common things that a framework will map at all (lifecycle management, foreign keys, inheritance, contention). I'm sure I missed a few, in that list, but it's a start. I didn't do anything about it, but I think those four things would make excellent subsections of the "Challenges" section later on the page. Lexspoon (talk) 14:00, 9 January 2023 (UTC)

Relational vs. Non-Relational

SQL isn't relational, and most of the mentions of 'relational' here aren't correct but refer to SQL actually. So I am correcting the article and will move it. Leandrod 19:58, 21 September 2005 (UTC)

I am sure there is an interesting hair being split here, but in general, "SQL" is the industry standard for accessing "relational" databases, and "ORM" is what this kind of tool is called. I don't know what more to say about the subject without understanding what hair is being split exactly. Is the issue that SQL is a pragmatic real-world language rather than an idealized relational formalism? But ORM tools are also pragmatic real-world tools. Suffice to say I agree with other editors who have changed it all back to "object-relational mapping". Lexspoon (talk) 13:57, 9 January 2023 (UTC)

I don't know what you mean by "SQL isn't relational" SQL is a language designed to act create, modify and select data from relational databases. In any case the whole rest of the world refers to what you've decided to call "Object-SQL mapping" by the term "Object-Relational Mapping" I refer you to the google score of 248 result for "object sql mapping" and 380,000 for "object relational mapping" with similar results with and without a dash. If the article needs to be clarified and improved please do so, but unless I hear back from you or others, I will move this article back to object-relational mapping, which, I strongly believe is where the vast majority of people expect to find it. Charles (Kznf) 01:16, 15 October 2005 (UTC)

SQL manipulates Relational databases, and therefore everybody refers to it as "Object-relational mapping". The correct title, I believe, should be Object-relational mapping. Everybody refer to it with that name anyway, so I believe this is misnamed. Remember that the underlying database engines operate with relations, while OOP programming language operate with objects. Mapping Objects to relational database fields merely uses SQL as a means, because allmost every db engine on the planet uses SQL as its query language. 80.212.120.4 20:07, 22 November 2005 (UTC)

This is vandalism it will be cleaned up Real Soon Now. Look at the history of the article and pich a version before User:Leandrod replaced relational by SQL. —R. Koot 23:10, 22 November 2005 (UTC)

I've changed the references to Object-SQL mapping to Object-Relational. While SQL isn't purely relational, this has nothing to do with O/RM - SQL is just a means used to perform the mapping to the relational database - there are O/RMs for non-SQL databases too. Object-Relational is also the term used pretty much everywhere (including much of this article) - Wikipedia should be describing the term, not redefining it. I've also removed the discussion about purely relational DBMSs - it doesn't belong here, and a lot of it seems wrong. Impedance mismatch, for instance, has nothing to do with how relational SQL is - it would still exist with a purely relational language too (In fact, it would probably be worse, since OO has some concepts, such as object identity independant of state, that go against a purely relational model.) Brian McErlean 01:18, 22 December 2005 (UTC)

Cache

The author of this article seems to be slagging on the Cache database a bit. However I the Cache's claims to multidimensional database are on the level as far as I know.

From their website:

>>Innovative Database. Guaranteed Performance.

CACHÉ is a multidimensional database that uniquely combines robust objects and robust SQL, thus eliminating object-relational mapping. Caché enables rapid Web application development, extraordinary transaction processing speed, massive scalability, and real-time queries against transactional data - with minimal maintenance requirements.

Cache is based on the MUMPS programming language and database. I beleive their claims to true multidimensional database cabability to be more true than the author of this post-relational database article claims. Comments, Suggestions?

65.213.63.17 20:17, 19 July 2006 (UTC)Ira Carmel

XForms

Do any of these tools support or help generate XForms XML? --JonathanFreed 14:53, 29 March 2006 (UTC)

Firestar lawsuit

News broke today that a company called "Firestar Software" is suing Red Hat, owners of the JBoss software, over infringement of a patent which appears to cover ORM. I need to think through whether/how to add that info to the article, but wanted to add a note about it here to remind myself and anyone else who wants to work on writing it up.

An article about the suit is here: http://www.infoq.com/news/RedHat-Sued-Due-to-Hibernate-3-O Ubernostrum 15:26, 30 June 2006 (UTC)

ObjC version of EOF, where?

Could someone point me to the ObjC version of EOF that is mentioned in the article. I have been under the impression that ObjC version was killed soon after Apple bought NeXT and Java version is the only one there is.

If you can find a copy of WebObjects 4.5, that includes the Objective-C version of EOF. —Preceding unsigned comment added by 24.7.121.38 (talk) 03:50, 18 August 2008 (UTC)

Object-relational modelling

Is there a difference between this and Object-relationship modeling? If not, should these two pages be merged? Agreed. This article should take over Object-relationship modeling.

I've made the Object-relationship modeling page redirect here. There wasn't really any content in there that isn't already in this article (and written in a better style) so I didn't add anything to this article. Mutant 17:54, 27 February 2007 (UTC)

Links

There are far too many links. Please limit to only authoritative and well-organized sources. --Froggienation 20:30, 12 February 2007 (UTC)

Can we have a list of languages/technologies that utilise this technique? —Preceding unsigned comment added by 79.64.169.41 (talk) 00:34, 16 April 2009 (UTC)

Critique

It appears that the critique is violating NPOV, and seems very much like a personal opinion. It states as fact that ORM is a non-problem, and fails to explain or cite the fundamentals of data management, or explain why they are considered to stand in opposition to ORM. No citation is provided for the failure of Object Databases.

Also, it seems biased towards Java, where this should be an (OO) language-neutral discussion; it talks about JDBC specifically.

I'm considering editing it, but I think I'd be happier if the original editor made it less personal and provided some citations.

The language in this section needs to be simplified. --Heycarsten (talk) 01:20, 18 July 2008 (UTC)

Racecondition 17:00, 31 January 2007 (UTC)

Agree, removal of strong emotive language with no references would be a good ida. But not by myself, seeing as I don't know much about the topic and came looking to learn more.

Agree. In fact, I think the whole section should be removed. It's completely baseless, and unreferenced. There should be a "criticism" section in this article, but I don't think there's a single factoid in that section worth keeping. Mutant 17:16, 9 February 2007 (UTC)

I read the Critique and immediately came here to remark on the NPOV issues. But, needing a definition of ORM, I thought it was valid criticism, if emotively worded. ('Utter failure'! I can't imagine using this in any form, written or conversational, without provoking an argument...) We should point out the objective facts underlying this:

1. it's easy to convert a fetched database record into a containing object or structure; (although the problems - missed by the criticism - are that code is repetitive, and must correspond with the data structure in the DB and therefore becomes a source for inconsistency errors);

2. relational databases hold the lion's share of the market - not that I have figures, and a citation would be required, but SQL server, Oracle, and MySQL together (and I'm not trying very hard here) must hold most of the market by money spent, users served and developer hours. Or it might be easier to find stats by required job skills?

The second paragraph ('impedance mismatch') has a core of truth; however, while I can see the relevance of the analogy, there's no guarantee that every reader would follow it. --Froggienation 20:30, 12 February 2007 (UTC)

I removed the first paragraph as soon as I read it, it's so obviously biased and specifically bases it's primary point on JDBC, which is Java specific when the article not language specific. I left the second paragraph intact since it wasn't an outright rant like the first paragraph. --mikeal

"The correct mapping in the relational model is between object and type." Are you sure? Class and type maybe...

What does "type" mean in this context? It isn't declared in the article. —Preceding unsigned comment added by 81.207.148.46 (talk) 08:57, 29 December 2007 (UTC)

"But in general, the pros outweigh the cons when using this paradigm." This statement is a judgment by the author. Pros and cons should be listed, but it's up to the reader to decide whether the pros outweigh cons. —Preceding unsigned comment added by 150.228.40.142 (talk) 18:34, 9 April 2009 (UTC)

I agree that Wikipedia shouldn't have bald opinions of individual authors. That said, there's a lot of potential encyclopedic content around referring to standard critiques and defenses of ORM. I'll say this non-neutrally on the talk page: having worked for years with ORM tools, I find that they make an easy problem even easier (tedious code to map columns to fields), but then add their own problems that are often really hard and time-consuming to solve (loss of control around locking, reading way more data than you need before making a small edit, reading back data after a save that you usually just throw away anyway, way more complex update commands than if you wrote the SQL by hand), plus the experience of pervasive mystery about what your program is doing. That's on the critique side. I am sure it depends on context, though, and that there are people with good experiences that could provide a defense of these tools. For example, some databases are just used by a single user at a time, in which case a lot of the cons won't really be an issue. Lexspoon (talk) 14:16, 9 January 2023 (UTC)

New Proposed Article

I'd like to propose a new category with corresponding article to catalog all the ORM technologies available in the different languages. It would include Hibernate, NHibernate, SQLAlchemy, ActiveRecord (Rails), etc. --Kibbled bits (talk) 13:55, 3 July 2008 (UTC)

Problem Description

"However, many popular database products such as SQL DBMS can only store and manipulate scalar values such as integers and strings organized within tables." This isn't accurate. The major RDBMS products (and the SQL standard) incorporate storing and manipulating object data. See the Wikipedia article on ORDBMS. Also the OODBMS article refers to SQL support in those products. Object persistance is less widley used than the relational model, except in specific domains such as geospatial data where the object definitions are fixed. The rise of ORMs would suggest that the Object/Relational Mapping problem is easier to address than the challenges of persisting object data.

Test Section

Test Section —Preceding unsigned comment added by 121.243.32.14 (talk) 06:49, 16 September 2008 (UTC)

Dubious

Most ORM frameworks now should deal with simple joins very well, and even complex ones if following certain templates. The bulk deletions would require custom SQL, and probably are not well done through ORM tools -- Q Chris (talk) 15:16, 18 October 2010 (UTC)

Tend to agree. (If Zend Framework can handle joins okay, surely software that doesn't suck must have gotten it by now.) What would be really awesome is if we had a source saying something about it, of course... —chaos5023 (talk) 15:24, 18 October 2010 (UTC)

Sourcing it would be good - but so far all I have found are blogs or framework documentation saying that their own framework is good. Both Toplink and Hibernate rate themselves, justifiably by my experience. -- Q Chris (talk) 17:38, 18 October 2010 (UTC)

Controversy

There's not a single citation in this new section and it looks biased and like POV OR to me. The "emerging trend" is that ORM is being banned? Where not, it's being used accompanied by "heavy justification"? If anybody can find a survey that asked CIOs how heavy the justification needs to be for them to allow ORM to be used in their organisations, I'd love to see it. How heavy are we talking here anyway? Like a boulder? An elephant? Maybe a Blue Whale? Oldernews (talk) 12:14, 15 December 2010 (UTC)

Agree, its certainly not my experience. -- Q Chris (talk) 12:35, 15 December 2010 (UTC)

Seems to me that this article is more for those who want to find an alternative to ORM rather than to those who want to know more. —Preceding unsigned comment added by 77.12.17.244 (talk) 07:40, 2 January 2011 (UTC)

To Dougluce - I think you need better sources than that, "self-published media, such as books, patents, newsletters, personal websites, open wikis, personal or group blogs, Internet forum postings, and tweets, are largely not acceptable as sources." From http://wiki.riteme.site/wiki/Wikipedia:Verifiability#Self-published_sources

To 86.30.37.126 - ('no citation is needed, it's an inherently true statement, eg 'an alternative wearing shoes is going barefoot') "An alternative to implementing ORM is use of the native procedural languages provided with every major database on the market. " This need a source - however 'inherently true' you see it. Williajm (talk) 23:11, 9 February 2011 (UTC)

There is currently a lot of heated talk about ORM as an anti pattern due to incorrect abstraction and inefficiency. Right or wrong and I feel some of this controversy should be mentioned. [1] [2]

"An alternative to implementing ORM is use of the native procedural languages provided with every major database on the market. " - This should be removed, it is not one of the main alternatives when discussing ORM alternatives. [3] [4] — Preceding unsigned comment added by 82.21.217.6 (talk) 07:57, 10 July 2011 (UTC)

This section has now twice been deleted (once by me), and twice restored by Q Chris.

This section should go, as it's unrelated to ORM within the scope of this article. It's also barely a referenced section, more of an external link with a caption on it.

ORM is about mapping between objects within the client and an RDBMS. This section is not - it's about applying OO paradigms to SQL coding, to present an object-like interface at the native SQL call level. This is quite a different thing - the objects are in the RDBMS, not the client. If this approach is used for ORM (which it could be, although it shows no advantage for doing so) it would produce two sets of objects. The style of the ref is also one of those mid-90s "catch up" articles, when old SQL DBA greybeards realised they'd missed out on the last decade on comp sci and they needed to get out and steal some ideas sharpish, if they weren't to be seen as COBOL coders. Andy Dingley (talk) 10:33, 23 August 2011 (UTC)

Abstraction

Does the use of ORM potentially abstract the use of a particular database - instead becoming potentially an interface to as many database engines as the technology in use potentially supports. ORMLite for example claims "Supports MySQL, Postgres, Microsoft SQL Server, H2, Derby, HSQLDB, and Sqlite and can be extended to additional databases relatively easily."

I'm not sure if this is true across all ORM technologies. If it is then should this be made clearer in the article as an advantage to ORM? — Preceding unsigned comment added by 87.237.64.150 (talk) 09:34, 12 April 2012 (UTC)

Just an observation, but how much of an actual real world advantage is the ability to switch RDBMS without re-coding? Every significant (non-dysfunctional) project I have worked on has defined a single RDBMS at the beginning of the project; either by selecting one or having an incumbent that would take more money to migrate from than the total cost of the planned development. So, in an enterprise development environment (as opposed to an Open source project that may want to support MySQL and PostgreSQL and...) all an ORM gives you is a convenient syntactic sugar to instantiate objects. The cost of this sugar is having the mappings to maintain (instead of the hand-coded object loading code) and being abstracted away from the database. The last thing is a huge hidden cost as in my experience, it encourages developers to not learn how to optimize SQL in their RDBMS. For example, here's a blog post [5] which describes how to improve Hibernate performance. If the developer had hand-coded the SQL they wouldn't have to spend time digging into why Hibernate was hitting the database 24 times instead of once. Also, when you know a particular dialect of SQL e.g. Oracle you learn more efficient ways of writing SQL that takes advantage of features unique to Oracle. Yes that's vendor lock-in, but in reality most companies do not change RDBMS unless they have a really compelling reason because it is so costly for so little business benefit. Just my 5c — Preceding unsigned comment added by 203.161.88.62 (talk) 05:39, 20 August 2014 (UTC)

What about Micro OR/Ms?

Would be nice to see some information about those so-called "Micro OR/Ms" that came up within the last 1-2 years, namely Dapper, Massive, PetaPoco and others. — Preceding unsigned comment added by 81.14.229.174 (talk) 17:05, 20 November 2012 (UTC)

Data Mappers

I've added some information today about Object-Document Mappers and Data Mappers as a general term. These subjects are only related to ORMs and I was unsure if they belonged here - but there is no Data Mapper page on Wikipedia, but perhaps there should be?

Incorrect C# code?

This example C# line is given as a way to find the person with ID 10:

var person = Person.Get(Person.Properties.Id == 10);

However, it looks wrong to me. (Person.Properties.Id == 10) would yield a bool: either true or false. It isn't a lambda or closure or a method that can run to perform a search. Equinox ◑ 15:36, 7 March 2023 (UTC)

(Weeks later: I have removed the incorrect code.) Equinox ◑ 05:51, 23 March 2023 (UTC)