Page 1 of 2 12 LastLast
Results 1 to 15 of 16
  1. #1
    Join Date
    Dec 2004
    Posts
    22

    How do DBAs feel about ORM (Object Relational Mapping) tools?

    (Such as Hibernate for Java.) Indifference, hatred, acceptance, etc?

  2. #2
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    complete and utter insouciance

    what's an object?


    oh wait, i'm not a DBA

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  3. #3
    Join Date
    Dec 2007
    Location
    London, UK
    Posts
    741
    O/RM is frequently disliked and treated with caution by data professionals either because they've had bad experiences with it or because of a suspicion that it is only used as a crutch for those who don't bother to pay attention to database issues.

    If you are a DBA dealing with developers who want to use O/RM then I suggest you take the time to understand what problems they are trying to solve and how the chosen OR/M solution works at the database level. Make sure the testing strategy is adequate, especially around the scalability and concurrency aspects.

  4. #4
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    ORMs are an extremely efficient way for lazy developers to write fragile applications.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  5. #5
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    ORMs are a case of letting the tool drive the design. Building the house to accommodate the hammer, rather than the occupants or the landscape.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  6. #6
    Join Date
    Dec 2004
    Posts
    22
    Quote Originally Posted by blindman
    ORMs are an extremely efficient way for lazy developers to write fragile applications.
    Thank you!

    Actually I'm a developer who feels the same as those here. I'm just tired of fighting every new hire I come into contact with who thinks ORM is some kind of modern requirement for software engineering. Many will look at you like you're crazy for even suggesting not using it. I need to research more concrete reasons NOT to use such tools, because I've about had it with this silly quest for the holy "ORM" grail. Maybe I should write a little white paper or something.

    I've had experience with ORM (two versions of Hibernate, specifically) and it's been nothing but bad when you step back and look at the big picture. It makes doing a few things a little easier, but developers seem blind to the hidden downsides and costs of using it in the first place. After it's finally setup and working, they're all proud and talking about it's "success", but during the weeks it took to get things up and running sufficiently--I feel like we could have just sat down, done the work and used SQL for everything anyway!

    So in the end you have an always slower system (and the supposed "caching" seems to be a joke to me, especially when running on an environment with more than one app server), which may or may not be immediately maintainable when you get new help. SQL on the other hand--heck we could hire a cheap, energetic college grad straight out of school and probably do okay...

    I have a longer list of downsides than this but I'm always looking to add to the list. If anyone has any good articles or other resources on ORM flaws (especially if it's from a developers point of view), I'd love to read them. Thanks,

  7. #7
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Surely you have already come across this classic in your google searches:
    Interoperability Happens - The Vietnam of Computer Science
    ..and followed up here:
    Coding Horror: Object-Relational Mapping is the Vietnam of Computer Science
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  8. #8
    Join Date
    Dec 2004
    Posts
    22
    Yeah, I've seen at least one of those. Will check up on them again.

  9. #9
    Join Date
    May 2007
    Posts
    80
    It's just a matter of using the right tool for the right job.

    I've got "functionality" whereby multiple applications access the same database, some handling different data, some handling the same data. For example i have data coming from different sources that is supposed to be the same but it is verified as a matter of integrity check.

    Here i use plain old JDBC with SQL statements. The Java objects inside the applications simply don't relate to the database structure one-on-one. Some objects cover multiple tables, others just part of a table. It depends on what each individual application does. To actually use ORM would mean turning the database, whose design is optimised for the overal functionality, into a real monstrosity just to fit into the ORM picture.

    On the other hand i have some applications that do one thing only where the database is nothing more that a storage facility in function of the application. In this case i love Hibernate, simply map my objects let it do its job. Often i don't even look at the resulting database because i don't care, as long as it works after some testing, job done.

    However i do agree that many developers have turned into blind monkeys. Applying ORM's all the time without actually taking the time to answer the question: is ORM appropriate for the functionality at hand. In most cases quoting the fact ORM takes less time to develop with. Extremely short-sighted
    as they don't care about the overall picture, just there own little corner.

    So to answer the question, ORM is a great tool when used in appropriate cases.

  10. #10
    Join Date
    Dec 2004
    Posts
    22
    In my experience, DBAs go into seizures when they hear a developer say "they don't care" about the database. I actually challenge the assertion I always hear that ORM takes less time to develop with. Up front, possibly--but people lose sight of the hidden costs of the increased complexity.

    There is (and remember time = money):

    -Time to setup the ORM solution, troubleshoot if problems (likely)
    -Time to learn to use the ORM tool
    -Difficulty of finding someone who knows the ORM tool you use (vs finding anyone who knows SQL...)
    -Additional cost of paying someone to learn or ramp up to learning the ORM tool you use, if needed
    -Time required to tune performance
    -Decreasing quality of support over time for the particular version of your ORM tool, as new versions appear
    -Time required to upgrade your ORM tool if needed because the version you use is too far out of date to get adequate community/pro assistance when needed
    -Loss of entire database-specific features that a SQL solution designed by a DBA would have been able to take advantage of, due to the attempt of ORM to be "database independent" (which is rarely even needed)
    -Possibility of bugs in the ORM tool, and time lost tracking these down if they occur
    -Performance penalty of using the ORM tool
    -Additional cost of hiring more highly skilled maintenance programmers to maintain ORM applications, vs hiring more entry level programmers who know SQL
    -Increased demand on application server memory and processing requirements
    -Minimization of database caching, in favor of ORM tool application server level caching--a particularly interesting topic when in a multi-app-server environment (heck I've even heard that some ORM tools don't update the database immediately, essentially making data in the database stale when accessed via a different application server)
    -Inability (or additional time required?) to fine-tune queries to not pull back unneeded data (vs sql, simply select fewer columns)

    This isn't a trivial list of downsides. There may be a few that have good workarounds or tools that don't have the problem, but saying ORM is obviously "better" than a non-ORM solution is just plain hogwash. Even in the situations where it works well and doesn't impose too much additional cost, it's almost impossible to say that a non ORM solution would have taken any longer.

    But I'm thinking that I'd prefer to skip all forms of ORM entirely, even "manual" mapping via SQL. At the end of the day, it's just extra work that could be avoided, yet this 400lb gorilla is never noticed. (To continue the primate analogies.)

    If you're using an object oriented language, really it's about time we (as an industry) should be switching from RDBMS to OODBMS object databases like db4o or Objectivity/DB. Instead of all this ORM crap, we could just be typing: store(someObject); (etc) and be DONE. Or just use a non OO language and use the RDBMS more logically. Why are we doing this mapping nonsense? Sorry this turned into a rant.
    Last edited by Garoad; 08-25-09 at 17:33.

  11. #11
    Join Date
    Dec 2004
    Posts
    22
    Bringing this back to see if anyone new has anything to add about this endless battle.

    (Re-reading the mention of object databases above I should add, after researching the current state of the industry, they aren't quite ready for most applications. So RDBMS is still in charge..)

    I still feel the same about ORM and while I will concede that there may be some situations where it's acceptable to take the risk of using one under ideal circumstances, I've yet to confidently identify what those ideal circumstances would be.

  12. #12
    Join Date
    Dec 2007
    Location
    London, UK
    Posts
    741
    Quote Originally Posted by Garoad View Post
    Re-reading the mention of object databases above I should add, after researching the current state of the industry, they aren't quite ready for most applications. So RDBMS is still in charge..
    "Object database" doesn't have to mean anything different to "Relational database". An object class is a type. In principle an RDBMS supports any type of arbitrary complexity and OO programmers call those types "classes" and they call instances of those types "objects". Even SQL DBMSs these days support complex user-defined types. So "object database" ought to be a solved problem - and it would be so if it weren't for the major deficiencies of the SQL language, for instance SQL's lack of type safety and inheritence. It is SQL limitations rather than any weakness of the relational model that cause OO programmers to look for alternative database solutions.

  13. #13
    Join Date
    Dec 2004
    Posts
    22
    I don't disagree but I'd add that OO developers more often than not are simply looking for ways to avoid writing lots of wordy, complex SQL statements "to save time". And I don't deny that it can be time consuming - but it doesn't have all the pitfalls I mentioned in the list of ORM "hidden costs" above, either.

    Ideally for me a "database" would exist entirely in the same memory space as the application (i.e. in RAM, although obviously it would still need to retain state when powered down) and the app would simply access objects in the "database" directly in memory, no "mapping" or inserting into any outside source at all--just objects in memory being updated by code. If solid state really takes off maybe in 10-20 years that'll be feasible. An object database comes close to imitating this but unfortunately the tools and support (particularly for large enterprise software to connect to such data sources) just aren't there yet.

    But back to the present day... ORM...blah, is it worth it? There are alternative 'frameworks' to reduce the tediousness of using things like JDBC. I'm still curious to hear what DBAs think of ORM in general, especially Hibernate. I'm sure there are some with experiences out there...

  14. #14
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    I used to think they were junk based on the examples I'd come across in my wanderings. However, after tinkering with LINQ to Sql I was forced to reconsider.

    I think I feel about the same way about OR/M as I do about native CLR support in SQL Server... It's great IF the person using them understands the entire pipeline. It's terribly, terribly dangerous in any other scenario.


    Also, I figured I'd comment on how LINQ to SQL addresses the list of costs mentioned above. I fired the same salvo when I was first researching it and was pleasantly surprised by what I found:


    -Time to setup the ORM solution, troubleshoot if problems (likely)
    Open up Visual studio. Point it datasource. Drag and drop on to OR/M Surface. Profit.

    I can build a barebones DAL in about two minutes.

    -Time to learn to use the ORM tool
    If you know Lambda, you know how what LINQ is doing to your statements. If you know SQL, you already have an idea how to put those statements together in the first place. If you know Lambda very well and SQL reasonably well, you can even mix and match between various syntax styles according to your liking.

    -Difficulty of finding someone who knows the ORM tool you use (vs finding anyone who knows SQL...)
    It's baked in to the .NET framework.

    -Additional cost of paying someone to learn or ramp up to learning the ORM tool you use, if needed
    Same deal.

    -Time required to tune performance
    Takes about the same amount of time to tune a LINQ deal as a normal query. And, if need be, you can just make your fancy high performance view/sproc/what-have-you available to LINQ with another drag and drop.

    -Decreasing quality of support over time for the particular version of your ORM tool, as new versions appear
    This is the subject of some debate as it's still a little hazy about the relationship with Entity Framework.

    -Time required to upgrade your ORM tool if needed because the version you use is too far out of date to get adequate community/pro assistance when needed
    Install .NET. Done.

    -Loss of entire database-specific features that a SQL solution designed by a DBA would have been able to take advantage of, due to the attempt of ORM to be "database independent" (which is rarely even needed)
    LINQ to SQL only targets MSSQL. You can make use of pretty much all platform-specific features.

    -Possibility of bugs in the ORM tool, and time lost tracking these down if they occur
    Possibility of bugs in the homebrew DAL...

    -Performance penalty of using the ORM tool
    What might that be? Once we get in to the actual application side of things you're either abstracting out data access or you're not. You're paying the price regardless of whether that abstraction involves an ORM tool.

    -Additional cost of hiring more highly skilled maintenance programmers to maintain ORM applications, vs hiring more entry level programmers who know SQL
    You don't need highly skilled programmers to maintain LINQ to SQL applications. That's kind of the point.

    -Increased demand on application server memory and processing requirements
    Ever run the numbers on building an app server vs. a database server? It's much, MUCH cheaper to throw hardware at the app side of things. You also generally get much better control over fine grain memory management in an environment that is specifically designed for you to be instantiating and disposing of objects all the time.

    -Minimization of database caching, in favor of ORM tool application server level caching--a particularly interesting topic when in a multi-app-server environment (heck I've even heard that some ORM tools don't update the database immediately, essentially making data in the database stale when accessed via a different application server)
    n/a. You actually get more caching options in addition to what you're used to seeing.

    -Inability (or additional time required?) to fine-tune queries to not pull back unneeded data (vs sql, simply select fewer columns)
    Mark a property as lazy load and it won't be retrieved over the wire until it's actually accessed by the application. You get that for free.




    Those were roughly all of my criticisms on the overhead of an ORM before I did this LINQ business too. Those are the answers I've found so far.


    Oh, and in the spirit of objectivity, I should mention the a major failing I've found in LINQ is dodgy support for many-to-many joins.
    Last edited by Teddy; 01-28-10 at 23:05.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  15. #15
    Join Date
    Dec 2004
    Posts
    22
    Hmm, I do have some responses to much of that, but since I'm not using .NET it's not really relevant anyway. Were I to try another ORM tool, it'd have to be for Java.

    Then again, with all the idiots who think they know Java polluting the knowledge base with crap and stupid "magic" ideas, maybe a switch to .NET would be a good idea...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •