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


ORM Mapping


ORM Mapping

Author
Message
Phil Factor
Phil Factor
SSCarpal Tunnel
SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)

Group: General Forum Members
Points: 4870 Visits: 3031
Comments posted to this topic are about the item ORM Mapping


Best wishes,

Phil Factor
Simple Talk
Mark Dawson
Mark Dawson
SSC-Enthusiastic
SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)

Group: General Forum Members
Points: 181 Visits: 59
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.
EdVassie
EdVassie
SSChampion
SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)

Group: General Forum Members
Points: 14050 Visits: 3901
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 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005. 14 Mar 2017: now over 40,000 downloads.Disclaimer: All information provided is a personal opinion that may not match reality.Quote: When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist. - Archbishop Hélder Câmara
Phil Factor
Phil Factor
SSCarpal Tunnel
SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)

Group: General Forum Members
Points: 4870 Visits: 3031
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
ben.mcintyre
ben.mcintyre
Old Hand
Old Hand (373 reputation)Old Hand (373 reputation)Old Hand (373 reputation)Old Hand (373 reputation)Old Hand (373 reputation)Old Hand (373 reputation)Old Hand (373 reputation)Old Hand (373 reputation)

Group: General Forum Members
Points: 373 Visits: 403
One of my favourite sayings:
'It doesn't matter how big your gun is if it's pointed at your foot'

Oh, so true.
akl
akl
Forum Newbie
Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)

Group: General Forum Members
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.
peter-757102
peter-757102
SSCommitted
SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)

Group: General Forum Members
Points: 1747 Visits: 2559
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.
peter-757102
peter-757102
SSCommitted
SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)

Group: General Forum Members
Points: 1747 Visits: 2559
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.
Gift Peddie
Gift Peddie
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17240 Visits: 14456
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
mstjean
mstjean
SSC Eights!
SSC Eights! (937 reputation)SSC Eights! (937 reputation)SSC Eights! (937 reputation)SSC Eights! (937 reputation)SSC Eights! (937 reputation)SSC Eights! (937 reputation)SSC Eights! (937 reputation)SSC Eights! (937 reputation)

Group: General Forum Members
Points: 937 Visits: 2550
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
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