Object Relational Mapping tools like Hibernate have helped developers make huge productivity gains in dealing with relational databases in the past several years. ORMs free developers to focus on application logic and avoid writing a lot of boilerplate SQL for simple tasks like inserts or queries.

However, the well-documented problems with object-relational impedance mismatchinevitably cause headaches for developers. Relational databases are a specialized technology built on sound concepts, but they don’t necessarily line up to the object-oriented world. There are a few approaches and styles to using ORMs which have various pros and cons.

Read more at:

Java Code Geeks: Problems with ORMs

Very weak article. Why is this published here?

It's posted here due to the "Java Code Geeks" autoposting bot (a rival to the IBM "Frank Charles" auto-post bot from 2010), that just wants to generate links to their site, which in turn just replicates other peoples blog posts. As you say ... weak

I don't click on anything from JCG. Don't understand why they aren't banned from posting.

In my opinion an OODD like Versants, is head and shoulder betters than using any relational DB/ORM tool like hibernate, especially when dealing with highly complex data, such as that found with scientific and medical data. I think tools like Hibernate were created for developers whose grasp of OO concepts where shaky at best.  In terms of productivity, what could be better than having your object model, describe your database schema, and letting the DB manage the complexity under the hood rather than creating unecessary artificial relationships, and, yet another development artificact (mapping files),  as is the case with an ORM tool like hibernate.

.... In terms of productivity, what could be better than having your object model, describe your database schema, and letting the DB manage the complexity under the hood rather than creating unecessary artificial relationships, and, yet another development artificact (mapping files),  as is the case with an ORM tool like hibernate.

Well, maybe nothing, but the world is full of RDBMS ready to host data.

IMO, ORMs have their place because let you think in terms of objects and because are RDBMS independent.

This is very important when you develop a product that can be (almost) totally unaware of the target RDBMS.

Well, if you open your mind a little more then go with JDO that is storage independent by design since the beginning.

You still have yet more artifacts to maintain with an ORM/Relational DB tool. Thats a fact.

And. BTW. Versants OODB is more than capable of matching up transactionally with any RDBMS. To address your statement on "totally unaware of the target RDBMS." Well try this.

FooBar fb = FooBar new();

vdb.store(db);

What could be more unaware than that. No mapping file, no byte code manipulation, no artifical relationships. you open your mind.

What's more simpler than the code fragment above.

Is Versant DBO free / open source?

The subject of this discussion is 

Problems with ORMs

Not. Open source Vs. Free DBMS's

Apples and oranges. If you want to start a thread of this nature. Do So.

You still have yet more artifacts to maintain with an ORM/Relational DB tool. Thats a fact.

And. BTW. Versants OODB is more than capable of matching up transactionally with any RDBMS. To address your statement on "totally unaware of the target RDBMS." Well try this.

FooBar fb = FooBar new();

vdb.store(db);

 

What could be more unaware than that. No mapping file, no byte code manipulation, no artifical relationships. you open your mind.

What's more simpler than the code fragment above.

Can't agree more.

If yuo have the freedom to choose the target datastore technology.

But what if you want to be multi datastore ?

In this case, unless some magic, literally, you cannot avoid some metadata to instruct persistence layer on how and where store objects and attributes. We could argue on the complexity of certain metadata solution but, I think, the concept cannot be avoided.

On bytecode manipulation there is a huge literature so I would avoid any comment on this ;-)

What an idiotic article. Want to be taken serious, TSS? Remove this one.

whether its mapping object graph to relational graph or one object graph to another object graph, overlaying one graph on top of another needs some amount of graph theory skill. many of orm frameworks don't teach end user this graph theory - may be because these are still evolving(eg: hibernate 1-to-many mapping changed from hibernate 2 to 3.5).  So - possibly we can expect new ways of mapping association/inheritance etc in next higher versions of hibernate. hibernate  supports nosql (is that OOM - object to object mapping?). I don't know if one-to-many relation of Object world or arbitary data in multple locations can be mapped to a single table.

when  asking basic flaw of OOP - it could be data structure and functions should not be together, as mentioned here - http://www.sics.se/~joe/bluetail/vol1/v1_oo.html . by adding the F(functional) into OOP, OOP keeps evolving. So FOOP is better than either OOP or FOP. Still more things will keep getting added in programming languages/frameworks with aim being "DRY - Don't Repeat Yourself" principle.

I feel Erlang founders's previous link is a valid argument-  that data and function should be seperate, and both should follow its own complex inheritance-association hierarchy for creating powerful reusable algorithms and data structures (seperately with all mix-n-match . this could allow chaining and many other things)...

if data and function are together in a object - Its like one function will behave as multiple algorithms based on object's state . This probably confuses end user in a very huge system ( say 90% of SOA interfaces are stateless - minimizing it- can't real world objects be stateless?). justification thatinstance variables link various entities together - could be implementable in seperated function and data structure classes as well.. suppose office has departments.. office department datastructure could be sperate from  functions of office/departmets.  adding instance variables along with functions of office class pollutes the way office functions.(?).

if data is removed from functions - it could make VM faster (eg: actionscript vm had to remove some programming feature  of ver 2 to make actonscript 3 faster)..

So many years of OOP, and - where are those powerful universally accepted  objects (still language designers may be confused)..

Says who.

I have been working in the OO world since Smalltalk.

So far I have yet to experience any other development methodology that allow the expression of intelligence and behavior in a more creative and expressive way. And. Siting  links that discuss pure theory does zero for me in the real world.

Even so. Your argument does zero to dispell the argument of OODB vs. Relational DB. As I said before. With an OODB like versant. I can development my complex object model with the confidence that the persistant store can do, what it needs to, to reliabality and robsutly persist my clients data. PERIOD.

Bashing ORMs because there is some new database product out there does not strike me as very insightful or productive. I opened versants homepage and discovered it's a database engine.

Many of our customers use Oracle/MySQL/PostgreSQL/DB2, and want to stick with this because they have DBAs in place already. It's all about risk management. In these cases I think ORMs like hibernate currently makes a decent job. It works, it's fast, it's database independent. Nothing is perfect, there is no silver bullet.

Cheers,

Tomas

Says who.

I have been working in the OO world since Smalltalk.

So far I have yet to experience any other development methodology that allow the expression of intelligence and behavior in a more creative and expressive way. And. Siting  links that discuss pure theory does zero for me in the real world.

 

Even so. Your argument does zero to dispell the argument of OODB vs. Relational DB. As I said before. With an OODB like versant. I can development my complex object model with the confidence that the persistant store can do, what it needs to, to reliabality and robsutly persist my clients data. PERIOD.

 

This would be funny if it wasn't so sad. I started using Versant back in the mid-90's (Version 1.6), when the growth of OO led many of us to believe that ODBMSs would have a very bright future. Like yourself, we struggled with mapping complex object models involving hundreds of entities and relationships, with applications including battelfield simulation, weather modeling, transportation and logistics, and image processing.

We finslly got fed up and ditched our relational database and our early ORM, and we couldn't have been happier. A few years latter we swallowed the entire jug of OO Kool-Aid, and ditched C++ for Smalltalk/Gemstone, and we were in nirvana.

Fast forward 20 years, and the same silly arguments continue. Use the right tool for the right job. If you're not doing large-scale decision support systems involving complex ad-hoc set-based queries, or trivial applications where ORM works OK, then an object database may be just the thing.

With the growth of data, we're now begining to look beyond relational systems. Just like ODBMs, products like Cassandra, and Hadoop address many of the shortfalls of RDBMSs. That's not to say that they're going to go away any time soon, but for specific jobs, relational databases, and their associated ORM frameworks, may not cut it anymore.

Mark

I really like this post but I think that the perspective (Relational>OO or vice-versa) is usually not an option but is set by the context: either a new application must use existing DB (usually RDBs with Beans) or it can be developped together with its own OODB.
More generally, since the pivotal mismatch comes from inheritance, the best option should be to build OO models using qualified subtyping constructs with relational mapping semantics.

I don't get the comment, "With its own OODB". I didn't know that I was developing "My Own OODB". When you develop with an ORM/RDBMS strategy, are you developing with "Your own RDBMS" ?

I'm not sure about what you're doing. But. I'm using a fully developed OODBMS system by Versant.

The ORM fashions such as Entity bean, JOD1, JOD2 and JPA come .. and then being reprobated, but the classic SQL will not.

The good news for advocate of ORM is that they might still have a chance to learn SQL with HTML5 storage.

The ORM fashions such as Entity bean, JOD1, JOD2 and JPA come .. and then being reprobated, but the classic SQL will not.

WTF is JOD? Perhaps you ought to read your dictionary before posting next time ("reprobate"). So JPA is "rejected by God" ? Clearly we've got a new level of FUDDer on TSS now.

I just caught that. How F'IN hillarious !!

OMG ... I have even forgot how to spell it correctly. Do you still remember their query language? 

The ORM fashions such as Entity bean, JOD1, JOD2 and JPA come .. and then being reprobated, but the classic SQL will not.

Rejected? Is JPA rejected? By who? Entity Beans, too? You know they are part of JPA, right? Do you understand the subject?

I stick by my position. My like clients like productivity, and so do I. As I stated earlier. If you're working in an Object based world, as, the majority of us are. I say use a persistence tool that was developed from the ground up to persist. Objects. Not tables. So far. In all the defences that have been posted of ORM's. I still have heard nothing which makes me think. Maybe there is a point there somewhere. I'm always going to stick with the ability to persist the object in a simple intuitive way. Your object model. Is your schema. There is nothing simpler than that. I don't need, or, want to know, how thats done. I just want to be sure that is managed correctly. Objects and Relational Tables, a natural inequality, forcce fitted by many developers inability to fully grasp OO concepts.

You must be lucky with clients who are willing to build from scratch, buy OODB license and go into production with it.

Clients I've seen so far are different

- They have infrastructure, DBAs and investments into one or a few of major RDBMS.

- They want as little of vendor dependency as possible

- They want seamless integration with their ETL and reporting tools.

- Their operations are hesitant to anything new.

And all that was about in-house applications. Now imagine company building a product. Forcing client into buying OODB license is unlikely to increase their sales.

So while abstractly idea of pure and transparent object persistence looks well, it may not always fit into reality constraints of paying customers.

You're right about being lucky. Very lucky in fact. My client is also a techno enthusiast. Healthcare informatics domain. I didn't have to do much selling on the idea. The CEO already understood the benefits of an OODBMS vs. RDBMS. Starting out from the gate, our productivity gains over a similiar project using an RDBMS were massive. It really set me and my guys free to be creative, and , not be concerned how things were going to be persisted, not having to be concerned about mapping files, and how could Hibernate handle recursive data structures etc...

problems with Ors are a hassle :(

buffalo freelance website designer

i encountered this problems and its a bug that needs to be fixed

stork club new york