Object-Relational Mapping is the Vietnam of Computer Science

“Personally, I think the only workable solution to the ORM problem is to pick one or the other: either abandon relational databases, or abandon objects. If you take the O or the R out of the equation, you no longer have a mapping problem.”

Thank you.

“yep it is what it is”

When OR/M is the Vietnam of Computer Science, I just saw the My Lai of Computer Science in a proprietary (read invented just here) implementation of an OR/M.
(just to make it clear: I do not mock the people who suffered way back when!)

ralf

Simply put O/R mapping is usually justified by comments like…
it gives me objects and it takes care of transactions.

I have two classes:
JdbcBroker.java
TransactionManager.java

I don’t need any ORM any Hibernate or any other junk solution.

I have no idea why it is so hard for everyone else.
Maybe they should learn the SQL language instead of hibernate.

People use O/R M because they don’t know SQL very well. (entry level programmers)
What is funny… or not funny… is that after so long, the application is so slow and sluggish and messy that they start writing ORM-SQL directly and get results sets again to speed up parts of the application.

Have you ever seen a five year old run in circles?

Can you say maintenance nightmare on jelm street.

It’s like using your old ford truck to pull your new semi.

I couldn’t have said it better myself.

On a quite Chevy night, you can hear a Ford rust.

On a long Hibernate night, you can see a shooting JDBC star.

HIBERNATE IS A NIGHTMARE JUST LIKE THE VIETNAM WAR

very good article and thread… not enough discussion in the world regarding whether object oriented middle tier approaches are cost and risk effective!

it all comes back to basics, what we learned in school about program elegance and such. way too much effort has been applied by software vendors to sell middle tier tools than concentration on whether those tools are necessary.

i find the argument that you either go oop or not at all a very compelling one. in the environments that i work in, all of the applications are data centric. the application is modeled relationally… for all the reasons that keep relational databases the kings of the resource/persistence layer. data centric applications should always focus on maintaining the relational model all the way through to the presentation layer.

attempts to take “data centric” applications and make them “object centric” in the middle tier is like slamming a square peg in a round whole.

either one goes “data centric” and gives up the benefits of the object world or goes “object centric” and gives up the benefits of the relational world. no free lunch!

Do you still feel this way about ORM tools (espcially for web development).

A couple of companies I use have them (like DevExpress and Telerik).

I had to laugh at the comment that talked about relational databases being the most efficient and fastest way to store data.

The relational model and RDBMSs were adopted in the 1980s IN SPITE OF their slowness compared to the then-dominant pointer-based hierarchical databases. Ask yourself why that was. If you can’t figure it out, buy an old edition of Date’s An Introduction to Database Systems (Vol. 1) and read it. The old editions are really cheap (used), and have discussions of the problems of competing data models.

When I started looking into OOP in the early 80s I characterised it to my colleagues as systems programmers discover the Entity-Relationship model. Building on what Buggy Fun Bunny said above, many of the seminal OOP papers in the 1970s referred to The Entity-Relation Model of Data in Proceedings of the 5th International Conference on Database in their bibliographies.

So not only the physical model (of relations), but also the semantic model (of entities, attributes, and relationships) underpin OOP. If there’s an Object-Relational mismatch, you’re doing OOP wrong.

Again, as Buggy Fun Bunny says, the 1960s and 1970s were spent learning why we should separate data and function. Storing them together in application-specific formats is exactly the wrong thing to do. We’ve been there before, people.

And as for Jo Script-kiddy who wants to put up a web site for the corner shop – why would she use C# or Java? That’s just masochism, when there are appropriate tools like PHP around.

I’m with “old_fart” here. If you think there’s a mismatch between OOP and RDB systems, you’re doing it wrong.

Here’s my approach, honed by 10 years’ experience and my comp sci degree (which was long enough ago that we studied network, hierarchial, and THEN relational databases in that order, since all were still currently in use by corporations – we learned C, then C++ because it was new and cool, and I didn’t pick up Java until I got out in the world).

FIRST, before you do anything else, get an entity-relationship model of your data. Learn how each piece of data relates to the others, so you can actually make a wise decision about what to do with it. The ER model should be an accurate model of reality; don’t pull any optimization stunts here, or you’ll regret it later!

NEXT, build your database. The database ALWAYS comes first, since it’s separate from your application and will exist long after your application has faded from memory. You must plan your database according to the assumption that other applications will use it, and that it will be extended to contain data about things you haven’t even thought of yet. And put your database in 3NF, so future developers’ suffering will be minimized.

Once you have an actual data model, print out your ER diagram and let your developers design their object model. Their object model should be based on your entities and relationships – object models are supposed to be based on reality, and your ER diagram is an expression of that reality. In other words, it should work like this:

Reality --> ER Model --> Object Model --> code

NOT the other way around. If developers recommend changes to the ER model, they should be made to justify them by showing how the ER model doesn’t accurately reflect reality. “coding convenience” isn’t an appropriate justification.

Finally, you build the actual software. You’ll probably use an incremental/iterative development model, and update the schema and object model as you proceed… That’s to be expected.

In the blog post, I’d be firmly in the “manual mapping” (#3) camp.

Note how this all works out. Because you’re basing your ER model, and then your object model, on REALITY, you’ll end up with a self-documenting system that is relatively intuitive to maintain. It’ll last a long time, too, because as long as the real-world entities you’ve modeled the whole system on continue to exist, the system will still be relevant. Changes in technology won’t ruin the system, because you’ve made the database the beating heart of it – you can always export and re-import your database structure to a new DB, and you can reuse your object model with a new language if something new comes along.

The whole idea here is, DO SOME ANALYSIS, and base your systems around an actual design, something that can be ported to new systems and extended over the years.

Of course, I’m an old fart too (38 years old!). And to me, the real problem is that “these damn kids today” don’t want to do any up-front analysis! They think that just because the waterfall model is a train wreck, they have a free pass to skip analysis entirely. Lazy little buggers and their PhP… THEY do cute little websites and they assume ALL development is about cute little websites.

Tsk, tsk, tsk… They just have NO IDEA…

Ah, well, glad to see I’m not the only old fart still around.

I didn’t dig deep into the comments, but from my skimming I find no one come forth and say why people want to put stuff in relational databases in the first place…

It turns out, your application is not the entire world. In most businesses there are several applications that need access to the same data. And before replies with the usual “make a service and let other applications access the data through it”, I’m not going to mention legacy applications (because you are stuck with an RDBMS anyway in that case), but I will mention ad-hoc queries.

Sure, you could build extensive ETL processes feeding a datawarehouse, but in the real world, there are people inside companies asking for all kinds of stuff to help them make decisions or to attend to specific oneshot needs within the organization (one shot stuff that often can’t be answered by the established datawarehouse). Being able to answer those queries without an RDBMS would mean full replication of all data from your object database into an RDBMS. It’s better to just go relational from the start.

It seems like the mismatch is often a false dilemma in the service of academic purism over creating actual working software. As BFB implied, tables can usually map pretty closely to the object model. In the odd case where they can’t a view can almost always solve the problem. OR/M’s do a great job of mapping objects to relational data as long as they haven’t stepped into a pre-existing conflict, and if the data architect was already at war with the software architect then an automated tool isn’t the cause or solution to the conflict.

Borland solved the ORM problem for me with ECO. It’s not perfect, but it saved me literally weeks of coding. When I found a little addon called ECOAccess it saved even more time. And it manages to generate a pretty clean database schema as well (I spend up to half my working hours as a DBA, so I’m not blowing smoke there).

Of course, it’s Delphi only, you won’t be finding a version for Visual Studio any time soon.

Anyway… RDBMS has its advantages, OOP has its advantages, and SOA also has its advantages. These things aren’t just useless extra “layers”, they’re tools which all serve different purposes (RDBMS for working with large datasets, SOA for implementing complicated business rules, OOP for writing more type-safe and maintainable code).

If you stop viewing these concepts as being at war with each other and start viewing them as different perspectives of the same solution, all the long-winded arguments about OOP and ORM and HBO and WTF start to look a lot more like lame excuses for ordinary human inertia (i.e. the overwhelming urge to keep doing things the way you’re doing them now, at any cost).

As many posters have said, ORM comes down to the tools (frameworks). I’ve been using Rails for a few months now, and I’m impressed at its ease and functionality.

For .NET, the Castle Project ( http://castleproject.org ) is also outstanding. Their ActiveRecord implementation is built upon NHibernate and allows your classes to be mapped using attributes, making for a smooth and joyful experience!