Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

ORM Mapping Expand / Collapse
Author
Message
Posted Tuesday, March 30, 2010 8:44 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Yesterday @ 10:36 AM
Points: 587, Visits: 2,530
Comments posted to this topic are about the item ORM Mapping


Best wishes,

Phil Factor
Simple Talk
Post #893451
Posted Wednesday, March 31, 2010 2:49 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, April 22, 2014 1:37 AM
Points: 167, Visits: 51
The core message of this article seems to be 'developers who don't know how to use ORMs properly can really mess things up'...
Isn't that true for any individual? If someone doesn't know how to use a tool effectively, whether they be a developer using ORM, a DBA using T-SQL, or a carpenter using a power-saw, things will inevitably go wrong!

You just have to trust that training and experience will eventually win out.

I think ORMs have their place and allow quite complex systems to be developed very quickly. DBAs shouldn't ban these tools or prohibit their use, but instead should become active in helping developers gain the experience to know when the use of such tools are a poor choice.
Post #893553
Posted Wednesday, March 31, 2010 3:04 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 2:46 AM
Points: 2,879, Visits: 3,229
ORM tools are here to stay, at least for a few years until the next big thing. So is Cloud. Both concepts spin the line that specialist skills at the database and operations layer are not needed. DBAs need to take this on board and work out how they can add value in this new paradigm, or risk being seen as no longer needed.

ORM and Cloud will move forward by dealing with some low hanging fruit. Third-party applications where the customer has little ability to change anything are prime candidates for Cloud. Small scale apps where ORM database inefficiencies do not cause SLAs to be breached are also headed for the Cloud.

This results in a large mass of applications that have a significantly lower development and operational cost than traditional 'optimised' applications, and businesses will be keen to see these cost savings across all applications.

The fact that some applications perform very poorly using the ORM model may become a driver for the business to find an alternative app that can get the Cloud and ORM savings, rather than be a reason for keeping the original application. This could be particularly true if the application is not essential to the main business profit drivers.

IMHO database professionals need to focus on adding value to the key profit drivers, and how they can minimise costs for everything else. For many people, even finding out what drives their employer's profits will be something new, while others will already be working on these lines.


Original author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2014, 2012, 2008 R2, 2008 and 2005. 28 July 2014: now over 30,000 downloads.
Disclaimer: All information provided is a personal opinion that may not match reality.
Concept: "Pizza Apartheid" - the discrimination that separates those who earn enough in one day to buy a pizza if they want one, from those who can not.
Post #893564
Posted Wednesday, March 31, 2010 5:16 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Yesterday @ 10:36 AM
Points: 587, Visits: 2,530
The core message of this article seems to be 'developers who don't know how to use ORMs properly can really mess things up'...


Sure. The message is that developers can really mess things up with an ORM.

Like Circular Saws, ORMs are great tools in the right hands, Like circular saws, the consequences of using them wrongly are difficult to put right.

The danger is in thinking that the use of circular saws means you can hire less skilled and trained carpenters!



Best wishes,

Phil Factor
Simple Talk
Post #893642
Posted Wednesday, March 31, 2010 7:53 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 7:44 AM
Points: 76, Visits: 379
One of my favourite sayings:
'It doesn't matter how big your gun is if it's pointed at your foot'

Oh, so true.
Post #893773
Posted Wednesday, March 31, 2010 8:37 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, June 10, 2014 9:22 PM
Points: 3, Visits: 51
I am going to take issue with your use of ORM in this context. ORM is an acronym for Object Role Modeling, a modeling technique and model query language. ORM is base on semantic conceptual data modeling and business rule validation and has its own set of graphical notation. It is arguably the most powerful modeling method to capture rules, restraints and relations and has been around for a long time see http://www.orm.net
The use or ORM for object/relation mapping should be called Object Data Mapping since the objects know nothing of relations to any other object. Data elements in objects are supposed to be encapsulated, free of dependencies.
Post #893832
Posted Wednesday, March 31, 2010 9:18 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 3:38 AM
Points: 329, Visits: 2,236
The first ORM I worked with was from the early 90s. It was a non public implementation, and I was unaware of any public ones at the time (the internet was young). Just several years ago, public ones started to come to my attention and they were essentially no more advanced as the one I used back then.

Newer implementations I haven't worked with since, but partial loading of object properties sounds like a very dangerous thing to me. A lot can go wrong with data/state consistency and as such I am far from convinced that it should be called "progress". I can see it work nicely when the property partitioning of a entity matches the horizontal partitioning in the database. Then of course it is hardly mapping, but just catching up to the real state in the database and cutting unneeded load overhead when possible (for large data types for example that are not always needed).

So I do see ORM's have a place, for those low hanging fruits where there aren't too many hard differences between the relational model and the object model as used by the programmer. But as soon as a application model gets more complicated it is just asking for trouble. In trying to paper over the mismatch you get hard to maintain and optimize code, with a generated base or not, which hardly matters at that point.
Post #893870
Posted Wednesday, March 31, 2010 9:31 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 3:38 AM
Points: 329, Visits: 2,236
akl (3/31/2010)
The use or ORM for object/relation mapping should be called Object Data Mapping since the objects know nothing of relations to any other object. Data elements in objects are supposed to be encapsulated, free of dependencies.

That is a questionable statement, since somewhere in any model, relations have to be stored. Does an order know which order details belong to it? Or does an order detail know to what order it belongs to?

One of the two has to be right in order to get access to data! Thus I would say the opposite as you and state there is always relationship knowledge stored in at least some of the objects. In what form is another matter as there are many possibilities.
Post #893897
Posted Wednesday, March 31, 2010 1:55 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Tuesday, September 9, 2014 9:10 AM
Points: 3,433, Visits: 14,429
ORM tools are here to stay, at least for a few years until the next big thing. So is Cloud. Both concepts spin the line that specialist skills at the database and operations layer are not needed. DBAs need to take this on board and work out how they can add value in this new paradigm, or risk being seen as no longer needed.


That is not my understanding of both tools ORM passes primitive to the RDBMS without data relations and more important without DRI(declarative referential integrity). Cloud on the Microsoft platform at the moment is used for fast changing and disposable data. There is a company running one terabyte every three months PeopleSoft SQL Server such databases cannot be moved to the Cloud.

ORM and Cloud will move forward by dealing with some low hanging fruit. Third-party applications where the customer has little ability to change anything are prime candidates for Cloud. Small scale apps where ORM database inefficiencies do not cause SLAs to be breached are also headed for the Cloud. This results in a large mass of applications that have a significantly lower development and operational cost than traditional 'optimised' applications, and businesses will be keen to see these cost savings across all applications.


The two are not related Cloud may use ORM but ORM is also used in most object applications that are data intensive. I would also not say ORM affects application performance if there is a clean relational model in the application, and care is taken to make the relational model RDBMS vendor specific.

The fact that some applications perform very poorly using the ORM model may become a driver for the business to find an alternative app that can get the Cloud and ORM savings, rather than be a reason for keeping the original application. This could be particularly true if the application is not essential to the main business profit drivers.

IMHO database professionals need to focus on adding value to the key profit drivers, and how they can minimise costs for everything else. For many people, even finding out what drives their employer's profits will be something new, while others will already be working on these lines.


The main problem with ORM is the concept of if a references b, b must exist is either not defined and in most cases application uses other convoluted ways to solve such problems.


Kind regards,
Gift Peddie
Post #894180
Posted Wednesday, March 31, 2010 2:17 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: 2 days ago @ 10:34 AM
Points: 436, Visits: 2,285
Phil Factor (3/31/2010)
Like Circular Saws, ORMs are great tools in the right hands, Like circular saws, the consequences of using them wrongly are difficult to put right.


In other words, "Beware the nine-fingered developer"...



Cursors are useful if you don't know SQL
Post #894195
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse