File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Object Relational Mapping and the fly likes Advantages of ORM? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Advantages of ORM?" Watch "Advantages of ORM?" New topic
Author

Advantages of ORM?

Vyas Sanzgiri
Ranch Hand

Joined: Jun 16, 2007
Posts: 686

I have used ORM in some applications. I find the following pros:
1. Caching
2. Easier to maintain transactions
3. Save across multiple tables and relationships

Are there any other points I am not using???

Thanks!


===Vyas Sanzgiri===
My Blog
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

This question gets asked a lot in this forum. Rather then repeat what has already been said, I recommend you have a browse through the older posts. You will find a wealth of opinion there.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

One of the biggest selling points that the Kodo people liked to bring up is that few people are expert in both Java AND SQL. ORM can eliminate a lot of gnarly SQL.

I had that forcibly demonstrated to me last month. I'm working on a project with a DIY pseudo-ORM subsystem, and, unlike true ORMs, it doesn't generate (or optimize) the SQL for you.


Customer surveys are for companies who didn't pay proper attention to begin with.
Vyas Sanzgiri
Ranch Hand

Joined: Jun 16, 2007
Posts: 686

I am surprised that few people are expert at SQL. I was taught SQL before Java and it is much easier than Java!
Mike Keith
author
Ranch Hand

Joined: Jul 14, 2005
Posts: 304
Well, yes, although I try to tell people that an ORM is not meant to hide the SQL layer from the programmer so much as do the heavy lifting for them. I am a firm believer (and I think Patrick agrees with me) that an ORM user should also be well-versed enough in SQL to be able to check the SQL that is being generated by the ORM and recognize problems, or make mapping or other query adjustments accordingly. The ORM should just make that easy to do without requiring a complete redesign of the schema, object model, or application code.

Like you said, it really does suck, though, when an ORM doesn't do sufficient optimization and also doesn't provide the hooks to enable you to cause it to be optimal.


-Mike
Pro JPA 2: Mastering the Java Persistence API
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

Vyas Sanzgiri wrote:I am surprised that few people are expert at SQL. I was taught SQL before Java and it is much easier than Java!


Simple syntax doesn't always equal simple execution. You haven't seen some of the join operations I've had to do over the years!

Even Kodo didn't advocate complete ignorance of SQL. No programmer should be granted senior status without being well-versed in the construction, diagnosis and tuning of SQL.

However, it's a cruel reality that a lot of work is done by junior-level programmers. They're cheaper and besides, the senior people can't do EVERYTHING (although I seem to get more than my share of that!). An ORM allows relatively inexperienced people to do fairly sophisticated tasks without all the bends and kinks that come from complex table interactions. Or at least fewer bends and kinks. The one caveat to that is that with powerful tools, it's possible to make major blunders, which is why laying off all the senior people wasn't really such a good idea. Someone who does understand what's going on under the hood needs to review stuff periodically.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Vyas Sanzgiri wrote:I am surprised that few people are expert at SQL. I was taught SQL before Java and it is much easier than Java!

My experience is, though plenty of software developers can write basic SQL well enough, they are far from capable of expert SQL, a skill that tends to be the domain of the DBA. And remember "SQL" varies from database to database, so knowing SQL in Oracle 11 doesn't equate to knowing it in DB2 390 (for example)

But aside from this, the ideal goal of an ORM is so a developer used to the semantics of an object oriented world doesn't even need to even begin to think about terms like "constraints", "indices", "correlated subqueries" etc. You can judge how well this goal is achieved, but that is the idea.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

Paul Sturrock wrote: "SQL" varies from database to database, so knowing SQL in Oracle 11 doesn't equate to knowing it in DB2 390 (for example)


Shudder. That's the kind of thing that HR departments use to exclude otherwise-qualified candidates.

As standards go, SQL isn't the most shining example. underlying datatypes tend to vary. And DDL is really bad at that. Then again, DDL isn't even part of Codd & Date. It's vendor-supplied support commands that just happen to be lexically similar to SQL.

Still, I've not only spent my time in 2 or even 3 databases in a single day, and some days even in a single program. I don't find it all that wrenching an experience.

In fact, my biggest gripe database-wise at the moment is that apparently IBM in its infinite wisdom doesn't have a way to migrate actual DB2 databases from their iSeries product to their Linux products. The dump format is machine-specific, and getting an ETL tool in a position to access the live database is going to be a political challenge. Trebly irksome since the 2 main open-source databases can do dumps to raw SQL and even make them (mostly) vendor-independent.
Mike Keith
author
Ranch Hand

Joined: Jul 14, 2005
Posts: 304
Let's be clearer.

<soapbox-text>

There are three categories of reality: the ideal case, the best case under the circumstances, and the common but sad case.

The ideal case is that there is a DBA that can inspect and comment on all of the SQL that gets used and generated. They will have created the schema to begin with (the schema generation tools from the entity model would NEVER be used). The Java developer knows enough about Java and SQL to be able to map and make changes according to what the DBA suggests and make the best possible use of the db features through the mappings. The application will be faster and the data will evolve in a way that follows the best data modelling practices. This is crucial since the data will almost always outlast the application.

If there is no DBA around the Java developer has to do all of the DB work and tuning. In order to do this they should know enough about SQL in order to do a good job of it. They may start with a generated schema, but should be proficient enough to be able to come up with a better, more optimized schema that meets both data modelling best practices and the ORM needs without having to go through mapping gymnastics. Having a correct and efficient schema is key (no pun intended) since every query could potentially be affected by a poorly designed and badly tuned one. A Java developer that is tasked with managing the SQL had better do some studying and learning if they don't know SQL but are charged with the database management. Bad data modelling will cause every application that accesses the db to suffer.

In many cases, however, the ORM is used as exactly what some of you have described -- a shield from the database. Java developers that do not want to learn the constructs of SQL think that they can get away without it by using an ORM. They do this at their peril, however, because while the ORM generally does a pretty clever job of most of the mappings and queries, and is always trying to do things the most efficient way, it is not trying to place a cloak of invisibility over the db. It's job is to provide all of the mapping and querying code to the developer so the developer does not have to rewrite it. While the developer does not have to understand all of the implementation of the ORM, they should understand the essential design and architecture. If they can't understand the generated output, why it is generated, and how to change it if it needs to be changed, then their applications tend to be poor, slow and incorrect.

When ORM became more popular the third case unfortunately became more common, but that doesn't mean that it should be acceptable. People should be told when they use ORM what the ORM is for and how it should be used.

</soapbox-text>
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

You can replace a lot of the above with "IDE" and it'll sound a lot like what I've been ranting on for some time now. PHB-types and bean-counters think if you give power tools to children it eliminates the need for adults.

I think a more common scenario - at least in medium-to-large shops is that the DBA isn't involved with each and every database. The schemas are often designed by the development team and handed over when the system goes into production. The DBA is responsible for the overall availability and performance of the database at the enterprise level. This may trading off performance between systems or, if a system is exceedingly offensive, showing up at someone's cubicle with Instruments of Pain.

There's rarely a direct link between source and object on almost any enterprise-grade IT resource anymore. Java has its ability to sense and recompile (re-optimize) on the fly. Oracle 10 allows the DBA at the admin console to cause the SQL that the programmer coded to be dynamically replaced with something that better achieves the enterprise service level agreements.

ORMs are part of this trend as well. While raw JDBC is in theory, more efficient than using an ORM, I've seen some benchmarks indicating that in some cases, an ORM can provide twice the performance of raw JDBC.

I spent much of the early years of my career doing assembly language programming on mainframes. I'm at least as devious as the next person when it comes to micro-optimizations.

However, I pretty much swore off assembly language for good when IBM released their Pascal compiler.

It wasn't that I couldn't do as good a job at optimization. It was that I'd have to devote the rest of my career to a single app in order to keep things optimized to the degree that that compiler was doing. It could refactor algorithms, hoist code, change register allocations and do all the other tricks in milliseconds on a scale that would take me weeks to achieve the same results.

That doesn't mean that the work can be done by unskilled labour. But it does allow one to focus on the "big picture" secure in the knowledge that most of the small-picture stuff will take care of itself, leaving only a residue to be worked over more intensely.
Mike Keith
author
Ranch Hand

Joined: Jul 14, 2005
Posts: 304
ORMs are part of this trend as well. While raw JDBC is in theory, more efficient than using an ORM, I've seen some benchmarks indicating that in some cases, an ORM can provide twice the performance of raw JDBC.


That's due to the ORM cache, a vastly underestimated (and sometimes misused) advantage of ORM
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

Mike Keith wrote:
ORMs are part of this trend as well. While raw JDBC is in theory, more efficient than using an ORM, I've seen some benchmarks indicating that in some cases, an ORM can provide twice the performance of raw JDBC.


That's due to the ORM cache, a vastly underestimated (and sometimes misused) advantage of ORM


I'm not sure but I don't think the last benchmarks I saw on the matter were crediting caching. Although I've been known to optimize JDO code to take advantage of cache.

Not that cache isn't one of the most important features of JDO. But it isn't that hard for a perfomance-oriented JDBC bigot to setup caching. Just less automatic.

On the other hand, some of the SQL traces I've seen from Kodo gave me the impression that the generated SQL was being tweaked to reflect actual data usage instead of doing things like blindly fetching everything in sight. Even Eager fetching doesn't necessarily mean you HAVE to scoop it all up at once. Just that the data has to be there when it's expected.
Mike Keith
author
Ranch Hand

Joined: Jul 14, 2005
Posts: 304
Dollar for dollar, running the same SQL through JDBC and generated from an ORM, the only real performance differentiator left is the cache. There is no JDBC cache over and above what a driver might do (in which case the ORM would get that benefit as well), so what you are left with is just the application. The object building is not typically going to be any faster in an ORM for example, and even if it could be the difference at that level is negligable.
Even Eager fetching doesn't necessarily mean you HAVE to scoop it all up at once. Just that the data has to be there when it's expected.

It's actually the other way around. When something is marked to be eagerly fetched it *must* be fetched, but lazy fetching *may* be fetched if the provider feels like it.
Anil Vupputuri
Ranch Hand

Joined: Oct 31, 2000
Posts: 527
Mike,

Does your book give any insight into Level 2 caching or does JPA2 support second level caching, it would be useful when dealing with large number of objects.


SCJP 1.5, SCEA, ICED (287,484,486)
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

JPA supports second level caching. Not sure how this helps when working with a large number of object - trying to cache large numbers of anything tends to shift the bottleneck to available memory (though of course, second level cache implementation may use a different persistent store).
Vyas Sanzgiri
Ranch Hand

Joined: Jun 16, 2007
Posts: 686

Paul Sturrock wrote:JPA supports second level caching. Not sure how this helps when working with a large number of object - trying to cache large numbers of anything tends to shift the bottleneck to available memory (though of course, second level cache implementation may use a different persistent store).


Been there! It was terrible. My server used to crash every 2 hours! I had no clue what was going on. Looks like it is not trivial to make it use a different persistent store
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Vyas Sanzgiri wrote:
Paul Sturrock wrote:JPA supports second level caching. Not sure how this helps when working with a large number of object - trying to cache large numbers of anything tends to shift the bottleneck to available memory (though of course, second level cache implementation may use a different persistent store).


Been there! It was terrible. My server used to crash every 2 hours! I had no clue what was going on. Looks like it is not trivial to make it use a different persistent store


Which caching implementation were you using? My experience is you can quite easily declaratively change where a cache manages its data.
Vyas Sanzgiri
Ranch Hand

Joined: Jun 16, 2007
Posts: 686

Paul Sturrock wrote:
Vyas Sanzgiri wrote:
Paul Sturrock wrote:JPA supports second level caching. Not sure how this helps when working with a large number of object - trying to cache large numbers of anything tends to shift the bottleneck to available memory (though of course, second level cache implementation may use a different persistent store).


Been there! It was terrible. My server used to crash every 2 hours! I had no clue what was going on. Looks like it is not trivial to make it use a different persistent store


Which caching implementation were you using? My experience is you can quite easily declaratively change where a cache manages its data.


EhCache. This was in Grails
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Advantages of ORM?