An unwritten consensus in the IT industry is that data shared between object-oriented software and relational databases is best exchanged with object/relational (O/R) mapping frameworks where the entity relationship (ER) model follows the object-oriented model. This article proposes a reversed, lightweight approach supported by a small framework called Amber.
Lightweight R/O Mapping
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Seriously, this is a HUGE drawback to this approach. Personally, I wouldn’t even consider Amber if it requires teh use of SPs.
Why? What is wrong with database-native stored procedures?
Nothing, besides they are database dependent (every database has a different syntax for stored procedures).
So, if you have a project that is based on a single database and will stay on it (like in-house projects in places with a very strong commitment to a single database vendor), a solution like Amber + stored procedures should be fine.
But in my personal experience as a software developer commitment to a single dbms is simply unacceptable.
Our software projects are written using Hibernate not only because we like OO, but also because our customers use different databases on different operating systems.
One of our products is deployed over four different dbms at different customer sites, each of which has a strong but different commitment to a database vendor (Oracle, DB2, Postgres, SQLServer). A friend of mine is working in another shop and they are getting crazy porting their application from SQLServer to Oracle because one of their top customers has switched database (and of course half of the app is written in stored procedures)
Gotcha. I understand where your are coming from. My experience is with companies that commit to one DB Vendor to maintain all their data internally. To me, at least currently, this would be a great solution, but I can see how it might not be as easily accepted for multi-DB use.
I would think twice before using it. I’ve read the article and the code he’s written is very slow, because it uses n+1 query to load an object and its dependent childs (the jedi and the fighters).
Hibernate on the contrary would issue a single query with an outer join and return the object properly formatted (one parent, many childs). This plus the ability to cache prepared statements should provide quite a performance boost compared to the silly example provided in the article.
Maybe Amber has a way to deal with the n+1 problem, I don’t know, since there is no web site with public documentation, but claiming high performance and then falling in the most common performance trap in O/R mapping is rather dumb…
Spoken like a true idiot. Sprocs are the only way to go for performance reasons first and foremost, with security coming in a very close second. That’s not the point though…the point is that the relational data paradigm maps very poorly to the OO data paradigm, which is undertandable as OO concepts are newer than relational concepts.
They both fit their programming domain just fine though (OO would be terrible at the actual data layer, and vice versa)…it’s getting the 2 to cooperate which is where O/R mapping comes into play, and makes programming against relational data far easier…and it’s hardly a new concept at that. Most non-trivial projects stand to gain quite a bit of productivity gains by using some sort of O/R mapping scheme.
There are many, many ways to do useful object-relational mapping, based on your particuar problem space. That is why there are so many OR mappers out there in every language. See http://en.wikipedia.org/wiki/Object-relational_mapping
First of all, your attitude is poor. Try to be an adult instead of slinging mud at the first person you disagree with.
It is true that in most cases stored procedures will perform and scale better than if they had not been used. In some cases the effort required to use them will outweigh the necessity…such as a smaller application w/ less users.
To say that they should be used in every application and in every scenario would be ignorant. Sprocs are a tool that have their place like any other approach.
I’ve written thousands of sprocs in my time for MSSQL, Oracle, Firebird, etc. and they’re great when you need them. On the other hand…the performance I’m getting from using Hibernate is exceptional and I’ve used it in the place of writing all of my SQL code (save for reporting queries.) This approach has allowed me to be many times more productive and is more times than not the approach that I take when designing a new application.
ORM has its place and is a great tool for the jobs that justify their use.
I was being as much as an adult as the commentor I replied to…no slinging of mud, but the comment reeks of amateurness; he stated that if sprocs must be used then O/R sucks? IMO, that sounds like idiocy, so I simply stated as much…and I feel most would agree. I appreciate your candor though.
why does the title say R/O when the article says O/R?
I don’t see why this is a contentious issue. It has been known for years that stored procedures, while effective for small things, greatly reduce programmer productivity over the life of a project.
Further, if one is arguing for increase performance gained by stored procedures (which is fallacious, btw), they are following the wrong carrot. As an enterprise architect, business owner and programmer, I will take increased programmer productivity over system performance EVERY TIME.
Now, to the arguments:
1. Security. People are specifically speaking about sql injection problems here.
Does anyone realize that you can have these with SPs? Anyway, that isn’t the true point. Any good ORM will make it possible to not even think about these problems (Re: hibernate, JDO et al). Heck, I have written a homegrown ORMs that are safe for PHP, Java and Ruby (all of which were far inferior to the much better open source variants available).
2. SQL vs SP. I have not written SQL in well over two years thanks to the great ORMs that are out there. This increases productivity and the speed at which one can develop an application.
Do you think that things like Hibernate, JDO, the multitude of .NET ORM (http://www.theserverside.net/news/thread.tss?thread_id=29914), ActiveRecord and all the others were just created because someone was bored? No…the severe limitation so SPs and the need to be productive at an ENTERPRISE level required these be created.
Those that argue for SPs on the enterprise level need to rethink why they use them. Things like maintainability, productivity and agility far outweigh clock cycles (if there is a speed gained with SPs, which is not clear).