• Jeff Moden (4/3/2011)


    Oh yeah... I almost forgot. If you're going to use an ORM so the "developers" don't have to work with the DBA and don't really have to understand anything about SQL or databases or so the "developers" can "design" databases via the ORM, then don't bring it inhouse. You will pay dearly for such a decision.

    This is precisely why I've seen ORMs adopted by several development teams and it resulted in exactly the kind of things you would expect.

    I firmly and honestly believe that ORM tools are wonderful and excellent when well used. I believe the same thing about firearms, excellent tools when properly used. But placed in untrained hands, improperly supervised, horrific results can come about. I've worked with four teams that decided to implement an ORM framework. Three of the four decided that the best way to do it was to eliminate any concept of database design from the approach. Only one of these three teams, as I write this today, actually has delivered their project. The other two are YEARS behind schedule, despite eliminating, what I was told, was the slowest part of the development cycle, database design. The one of the three that went into production is having lots and lots of performance problems (last time I looked, I left the company). The other two teams were having even more horrific problems. They hit everything bad, the N+1 problem, the inability to pull data for reports, excessive execution plans due to poorly laid out code, really, really bad tsql... the list goes on & on.

    That other group, the one that worked with the database developers to come up with a data model and use the ORM to actually MAP (which is what the "M" stands for) between the object and relational, they delivered the project on time, and it's very functional. They've had updates without issue. It works.

    In short, it's not ORM, it is how ORM is used.

    "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