SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The ORM Dilemma


The ORM Dilemma

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)

Group: Administrators
Points: 61565 Visits: 19099
Comments posted to this topic are about the item The ORM Dilemma

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
justin.trask
justin.trask
Forum Newbie
Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)

Group: General Forum Members
Points: 5 Visits: 27
As a developer having finished a couple of large projects using an ORM (Entity Framework) I can tell you that they add more than they take away. Most DBAs take issue with ORM frameworks because they feel they are giving their baby up for adaption. But if you consider that some frameworks such as Entity Framework still allow you to use CRUD stored procedures, Views and Transactions then there is not that much to be worried about.

Yes you do loose some finite control but it rarely a large issue. Yes in a very high performance scenario were sub seconds are important then I would second guess the use of an ORM and would really test the performance hit of using one before deciding on its implementation. But where the requirements for the application contains a lot of complex business rules and ongoing maintenance is likely to be a significant cost then an ORM definitely makes sense.

Using an ORM simply put increases productivity. Therefore gentlemen I would just get used to it. These frameworks are here to stay and it is best that you educate yourself about the various frameworks so that you can make a positive contribution to the discussion rather than being a roadblock to productivity.
bkubicek
bkubicek
SSCrazy
SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)

Group: General Forum Members
Points: 2998 Visits: 811
I think it depends on what your project needs are. If you have a more simple project with a simple db design something like the entity framework can work. I am still a little concerned over the scaleability of the entity framework. We recently used it in a new product we were developing. The bottom line was the product had a lot of complicated things that the entitiy framework just did not do well with. So in the end a number key pieces of functionaility had to be written in stored procs because the entity framework just couldn't do the work in a timely manner. Also the performance was not great even with the simple screens. Unfortunately for us it appears we will have to re-write this product without the entity framework before we can go to market with it. So in our case the entity framework has cost us a lot of money and time. Honestly we wish we had not used the entity framework to begin with.
Tom Garth
Tom Garth
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1239 Visits: 1499
I can't contribute much because you made me Google ORM. I guess I'll just follow the thread.

Tom Garth
Vertical Solutions

"There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves." -- Will Rogers

WI-DBA
WI-DBA
SSC Veteran
SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)SSC Veteran (258 reputation)

Group: General Forum Members
Points: 258 Visits: 605
We are even going through the debate currently of productivity vs performance. It will be interesting to see if the developers can pull off a quality ORM deployment. I hope they can deliver automated load testing so we can verify this thing won't eat up the Nehalem's when it goes live.....

@Justin - There is very little that a DBA needs to know about the ORM tools. The database needs to be designed properly; the rest is up to the ORM/Developer. Developers seem to see the roadblock to productivity as the initial code writing, but DBAs have to live with the implications for the life of the application. So is productivity only to release, or the time it takes to get the app to function properly and run without constant babysitting?

This will basically force developers to become administrators of their systems and the data layer, and the DBAs will simply gather metrics and send out reports showing why things are slow. Their power to fix them will have been diminished considerably. Personally, I know few developers who want the responsibility, and when I put it to them like that, they go back to writing procs.

The Scary DBA reflected on the problems awhile back, the one that many DBAs that I have talked to, encounter.-> http://scarydba.wordpress.com/2010/04/05/nhibernate-first-look-at-tsql/

Cheers
http://twitter.com/widba
http://widba.blogspot.com/
NYProjectLeader
NYProjectLeader
SSC Rookie
SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)

Group: General Forum Members
Points: 37 Visits: 112
ORM Frameworks are tools, and as with anything else, you need to use the right tool for the right job. Use the wrong tool, and you will break something.

I believe ORMs have their place, and if you can override their automatic SQL generation when needed to ensure good performance, then you are all set.

I had one project where it was critical for me to represent data in business objects, not just datasets. I estimated that in order for me to properly design the business objects and data access layer to not only hold data, but manage state, change tracking, concurrency, relationships, etc, it would have taken me about two weeks minimum. Using the Entity Framework, I was able to complete the same task in about 3 days.

ORMs are not the be-all-end-all of data access, but when used appropriately and for the appropriate tasks, they are good tools for getting the job done.
justin.trask
justin.trask
Forum Newbie
Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)

Group: General Forum Members
Points: 5 Visits: 27
Amen brother!
justin.trask
justin.trask
Forum Newbie
Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)

Group: General Forum Members
Points: 5 Visits: 27
@bkubicek I am surprised that a possible rewrite is necessary since you can use stored procedures inside of Entity Framework. I had the same problem for some instances where the standard LINQ functionality was not a good fit and therefore I went with stored procedure for some things but still inside of Entity Framework.

It might be a case where the development team is not fully leveraging the possibilities of the ORM.
bkubicek
bkubicek
SSCrazy
SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)SSCrazy (3K reputation)

Group: General Forum Members
Points: 2998 Visits: 811
The reason we decided the rewrite is necessary is that the performance is poor even with very little data in the test database. It is surprising how sluggish the web UI is with so few records to return. We considered only rewriting the pieces that were too complicated for the entity framework. Actually, we started down that path, but we could not resolve the UI sluggishness without removing the entity framework.
peter-757102
peter-757102
Right there with Babe
Right there with Babe (797 reputation)Right there with Babe (797 reputation)Right there with Babe (797 reputation)Right there with Babe (797 reputation)Right there with Babe (797 reputation)Right there with Babe (797 reputation)Right there with Babe (797 reputation)Right there with Babe (797 reputation)

Group: General Forum Members
Points: 797 Visits: 2559
The CRUD concept itself is very old (I know of implementations from over 20 years back). It is also kind of crude/limiting in that operations apply per record (from what I have seen myself). This is counter to more efficient set based thinking, which you need to do when working with large volumes of data.

In a way, completely depending on CRUD is a step wackwards to the day when there were products that had triggers that fired per record instead of per set of records. As a developer I can see the ease of use however, but it should never be implemented in a way that reduces the options for a DBA to optimize things after deployment.

If you need one record, manipulate one and store one, CRUD is fine. Beyond that, it becomes itself a roadblock for performance and efficiency.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search