March 30, 2010 at 8:44 pm
Comments posted to this topic are about the item ORM Mapping
Best wishes,
Phil Factor
March 31, 2010 at 2:49 am
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.
March 31, 2010 at 3:04 am
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: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
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
March 31, 2010 at 5:16 am
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
March 31, 2010 at 7:53 am
One of my favourite sayings:
'It doesn't matter how big your gun is if it's pointed at your foot'
Oh, so true.
March 31, 2010 at 8:37 am
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.
March 31, 2010 at 9:18 am
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.
March 31, 2010 at 9:31 am
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.
March 31, 2010 at 1:55 pm
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
March 31, 2010 at 2:17 pm
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"...
March 31, 2010 at 5:15 pm
In Steve's editorial from a couple weeks ago, Code Writing Code, he makes reference to Buck Woody's blog post, which made reference to NHibernate, which is a very popular "ORM" these days. I left a comment on Buck's blog, I also left a comment on Steve's editorial, and I'll leave another here because I can't stress enough how much I hate NHibernate and how it should not be used in any kind of development environment except for educational purposes. NHibernate, Hibernate, and I'm sure several others (I haven't used LINQ yet, so I can't say), just need to die and stop being used.
March 31, 2010 at 8:36 pm
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.
Typically the definition of ORM is "Object-relational mapping" - meaning that an OO model is mapped to a relational database model (usually a normalized model). As such, it has existed in some form or other for decades. Of course, the "relational" in relational databases refers to the "relation" or table, and this has nothing to do with the inter-table relationships but the relation of all columns on a row to a key - and the normal forms.
Primitive usage of ORM includes one-table to one-class mapping, but more sophisticated usage means that the object model and database design are more independent, each handling things in their domain according to appropriate best practices, with the ORM layer performing the mapping. As such the inter-object and inter-table relationships are usually handled very differently, as object collections or other data structures in OO models (where the relationship is more of an implicit style) and as many-to-many link/bridge table abstractions in a RDBMS (where the relationship is explicit). Typically keys in relational database are explicit, while those in an OO system are more ephemeral - usually as "object references". In OO models, data objects such as child collections are not free of dependencies (for instance a collection of addresses in a customer object).
Like any abstraction, using an ORM has a cost. However, in most cases, the cost can be made equivalent to the cost of hand-coding the objects and populating them from the database appropriately. Informed use of ORM then still requires recognizing when advanced features like lazy loading should be used to reduce database usage and when features are invoked, users need education and awareness about the underlying mechanisms used.
Primitive usage of ORM where a database is simply persisted from the object-model is a complete waste of using a relational database, and is what gives ORM a bad reputation in the database community. In apps like these, a relational database should likely not have been used in the first place. For relational access, they could simply ETL the data into a dimensional data warehouse model for reporting and analysis - eliminating a normalized database altogether.
If you want to store your OLTP data in a relational database, you should do it because in a relational database you have normal form (facilitating a small transaction footprint), ACID and you can define an appropriate database services layer of stored procedures and views which provide a common and consistent interface, not just to the ORM, but also to any other multi-modal application access - where going through the ORM (and creating many objects) is wasteful or unnecessary - such as reporting or ETL.
April 1, 2010 at 10:02 am
Primitive usage of ORM where a database is simply persisted from the object-model is a complete waste of using a relational database, and is what gives ORM a bad reputation in the database community. In apps like these, a relational database should likely not have been used in the first place. For relational access, they could simply ETL the data into a dimensional data warehouse model for reporting and analysis - eliminating a normalized database altogether.
If you want to store your OLTP data in a relational database, you should do it because in a relational database you have normal form (facilitating a small transaction footprint), ACID and you can define an appropriate database services layer of stored procedures and views which provide a common and consistent interface, not just to the ORM, but also to any other multi-modal application access - where going through the ORM (and creating many objects) is wasteful or unnecessary - such as reporting or ETL.
The above is a big problem because applications using ORM persists objects and ignores most rules of the relational model. I have also seen some that are just using tables without relationship but the worst I have seen was a multi use application running with only Data access. The person wants to move to x64 and I said no you need a relational model in your application. To be balanced there are ORM tools in the Microsoft platform that provides versions for SQL Server and Oracle.
Kind regards,
Gift Peddie
April 1, 2010 at 10:51 am
Gift Peddie (4/1/2010)
a multi use application running with only Data access
That's the real killer - people who treat persistent object data storage as dumb storage (generate the database from the classes, no-RI, no normalization, inappropriate data typing, etc.). SQL Server (and any relational database) is overkill for these people and likely will not perform as well as something they either cobble together themselves or some kind of object or document database.
If you are going to have a real database, it needs to protect its own perimeter. A database where anybody can dump data and provides no application-level or domain-level integrity or consistency guarantees or metadata services is no longer a database.
I don't have a problem with ORM, I have a problem with putting data in a relational database that doesn't use it properly. I've used normalized databases and dimensional databases - in all cases, the database itself has a surface interface of services which provides some coherent boundary of responsibility.
April 1, 2010 at 6:32 pm
That's the real killer - people who treat persistent object data storage as dumb storage (generate the database from the classes, no-RI, no normalization, inappropriate data typing, etc.).
I think most of the large companies that treat RDBMS as dumb storage are out of business but there are still many small companies thriving. I also think ACID is one of the main reasons because if you are running a clean relational model long running transaction gets passed through layers by converting to Unit of work transaction in the RDBMS without resource manager because the layers just participates in the transactions. Both SQL Server 2005/8, 2008 R2 and Oracle 10g R2 and 11g R1 and R2 participates in such transactions without resource manager in the Microsoft platform.
Kind regards,
Gift Peddie
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply