• Jack has largely nailed it. ORM tools speed up development, but at the cost on the database side of things. Using the tool straight, no modifications, you get lowest common demoninator SQL. This works for most of CUD of CRUD, but it doesn't work that well for a pretty substantial portion of the 'R' or reads of CRUD. What's worse, many of the ORM tools, nHibernate is my own personal bugaboo, allow developers to drive objects straight out to the database, turning the relational storage system into an object persistance layer. In other words, ignoring how SQL Server works and pretending that simply calling it something else will make all the icky parts of database work go away. Unfortunately, it doesn't. In fact, storing objects without thought to relational design leads to many problems when it comes time to retrieve the data for reporting or integrate with other systems.

    But, properly applied, working with the developers to arrive at a good relational desgin, monitoring development so that you can spot when a particular process needed a stored procedure rather than generated code, ORM tools could be a god-send for fast & accurate delivery of well structured systems. But I think that this is the exception and not the rule.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning