April 9, 2008 at 6:54 am
I really need some help on this one. One of our development teams is looking into ORM as a way to get code out the door faster. I've been doing a bunch of research on the topic (I'll post the links below) and I've found some interesting discussions over the pluses & minuses of the methdology. There are lots of positive examples of how well it works from all the vendors of various ORM products. I can't find any concrete examples of failed projects or long term maintenance nightmares or anything else like that. Even if ORM is the greatest thing since the flush toilet, there must be failures out there. Does anyone have any links or can provide any examples on failed or problematic ORM implementations?
I'm not trying to prevent the use of ORM, but I want as thorough an understanding of any possible problems as I can. Please help.
Here are a few of the links that I found useful:
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=78&t=000447
http://groups.google.com/group/ruby-talk-google/browse_thread/thread/938ae1538a84602d
This one is widely quoted
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
And answered directly
http://www.codeproject.com/KB/architecture/ORM_Vietnam.aspx
http://rapidapplicationdevelopment.blogspot.com/2007/08/create-data-disaster-avoid-unique.html
http://www.devx.com/vb2themax/Article/19894
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 1, 2010 at 3:31 am
Grant
Did you get any response on this one?
Thanks
JL
June 1, 2010 at 6:22 am
Not really. I've been posting about it on my blog for the last two years. Our project is... well, we'll see how it turns out. At the moment, I don't have much hope for it in terms of performance or maintainability. It'll work.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 3, 2010 at 2:21 pm
I wanted to say thanks for posting those links. They were very intersting.
November 21, 2012 at 9:30 am
Hi, Grant. Given it has been a while since your last post on this topic, and with the introduction of new releases of E/F, any new opinion(s)?
Thanks...Chris
December 8, 2012 at 10:17 am
I had to change this function from protected to public in Data Mapper (even though it is documented). Add your modules through a config or helper file. 😎
December 9, 2012 at 4:38 am
CGSJohnson (11/21/2012)
Hi, Grant. Given it has been a while since your last post on this topic, and with the introduction of new releases of E/F, any new opinion(s)?Thanks...Chris
Nope. Sorry. I left that company. I haven't heard anything in six months, but the last I did hear, they still hadn't released it to production. They were facing major performance bottlenecks all over the place. They had to build a second, normalized database, because they were unable to do even the simplest reports from the object-only database. It doesn't sound good.
I'm still not anti-ORM, but, it does seem that it's extremely easy to use an ORM tool in a horribly inappropriate fashion and that the ramifications from that are seriously far-reaching.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
December 9, 2012 at 7:32 am
OK...thanks, Grant.
August 27, 2015 at 9:51 am
August 27, 2015 at 10:10 am
7 year old thread.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 27, 2015 at 10:45 am
diegosiao (8/27/2015)
There is also this free .NET library, which is lightweight and very performatic:
It is a seven year old thread as Gail points out.
But, I have a question, how will DBBroker magically make a database built out of objects instead of relational tables work for reporting? Some of the fundamentals are there because, they are, in fact, fundamental.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 27, 2015 at 11:37 am
Wow, now I took a look... a 7 years post. I guess ORM is still an important issue.
I am little confused about the meaning of your replica.
ORM actually stands for Object/Relational "Mapping". It seems like you were looking for a database-first oriented ORM tool.
The tool I mentioned, is a code-first oriented. I.e. is able to generate the SQL script to create database objects that reflects a mapped model.
August 27, 2015 at 11:49 am
diegosiao (8/27/2015)
Wow, now I took a look... a 7 years post. I guess ORM is still an important issue.I am little confused about the meaning of your replica.
ORM actually stands for Object/Relational "Mapping". It seems like you were looking for a database-first oriented ORM tool.
The tool I mentioned, is a code-first oriented. I.e. is able to generate the SQL script to create database objects that reflects a mapped model.
Exactly.
The issues that created huge problems seven years ago were because of the code-first approach taken. Code defined objects, objects defined tables, all hell broke loose.
See, Object/Relational Mapping more or less describes what should happen, you have Objects and you have Relational storage, and the tool maps between them. It's not code-first and it's not database-first. It's understanding each tool, what it does, why it does it and using them appropriately.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 27, 2015 at 12:08 pm
I agree.
To a "from zero" robust corporative application, I think code-first oriented modeling is a good approach, taking advantage of the SQL script generation to revise it and then execute with appropriated corrections (or not, hopefully).
August 27, 2015 at 8:52 pm
diegosiao (8/27/2015)
I agree.To a "from zero" robust corporative application, I think code-first oriented modeling is a good approach, taking advantage of the SQL script generation to revise it and then execute with appropriated corrections (or not, hopefully).
The problem with that is almost no one ever goes back to make all the "appropriate corrections". For example, as a DBA, I just "love" it when someone defines a telephone number column and the system creates an NVARCHAR(256) column for it. Even better is when it creates a column using the NUMERIC(18) datatype for every bloody integer including those columns that will never contain more than a 1 or a 0.
While I appreciate many of the advantages of a "code first" approach, there are 4 huge disadvantages to it that make it totally not worthwhile, IMHO.
1) People who don't really know much about databases are the ones that frequently suggest the approach.
2) Because of that, they normally don't know enough to fix the generated scripts even if they were to look at them.
3) Even if they are pretty smart about databases, people rarely take the time to actually look at the scripts and fix them because it "works" at the time.
4) The cruddy auto-generated objects are usually good enough until the database final has some meat in it and then there's usually only one or two people that can actually fix it but there's so much to be fixed that the performance problems due to increased scale can't be fixed right away.
And, to be sure, the problems with "code first" doesn't just apply to front end code. A whole lot of batch file functionality is created in much the same way and with much worse effects because we're no longer dealing with just one row or one screen's worth of data anymore.
I've not ever seen a "code first" project scale well unless hundreds of servers are brought to bear in an MPP fashion. Most companies can't afford to do that so it also means that I also only ever seen one "code first" project scale.
Could "code first" projects scale properly? Yes they could... if they fix all the mistakes in the automatically generated objects and the people doing the work have a good understanding of the database objects behind the scenes. Usually, that's not the case and it makes for anything but a "robust corporative application".
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply