|WikiProject Computing||(Rated Start-class)|
- 1 Introduction
- 2 Relational vs. Non-Relational
- 3 Cache
- 4 XForms
- 5 Firestar lawsuit
- 6 ObjC version of EOF, where?
- 7 Object-relational modelling
- 8 Links
- 9 Critique
- 10 New Proposed Article
- 11 Problem Description
- 12 Test Section
- 13 Dubious
- 14 Controversy
- 15 Abstraction
- 16 What about Micro OR/Ms?
- 17 Data Mappers
"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. 188.8.131.52 (talk) 17:00, 16 March 2015 (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 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. 184.108.40.206 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)
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?
220.127.116.11 20:17, 19 July 2006 (UTC)Ira Carmel
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.
- 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)
There are far too many links. Please limit to only authoritative and well-organized sources. --Froggienation 20:30, 12 February 2007 (UTC)
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.
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 18.104.22.168 (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 22.214.171.124 (talk) 18:34, 9 April 2009 (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)
"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.
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)
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)
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 126.96.36.199 (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://en.wikipedia.org/wiki/Wikipedia:Verifiability#Self-published_sources
To 188.8.131.52 - ('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)
"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.   — Preceding unsigned comment added by 184.108.40.206 (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)
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 220.127.116.11 (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  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 18.104.22.168 (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 22.214.171.124 (talk) 17:05, 20 November 2012 (UTC)
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?