What a great way to phrase the issue. I love the concept of the people-people impedence mismatch. We’re going through it pretty regularly where I work. Our developers are convinced that using an ORM tool, in this case nHibernate, they’re eliminating all the problems with the database because they’re taking complete control of the database through nHibernate. All code will be on their side of the fence, no more messy stored procedures. All data structures will look like their objects, no more having to figure out those silly JOINS. Best of all, by setting all this up, no more messing with those stupid and obnoxious DBA’s.
Unfortunately, they’re still planning on object persistance (don’t call it data storage) inside of a SQL Server database… Um, guys, you haven’t eliminated a single problem. You’re storing your data in a less efficient manner and you’re using lowest common demoninator TSQL to access it… Performance is going to be a BIG issue. Scalability will also be a serious problem. All the problems that have been encountered are still there plus new ones. They seriously believe that not worrying about the idea of set based operations will just make the issues around data sets go away.
I understand why they want to do what they’re doing. I support the concept. Making development more efficient is a good and worthy goal. My problem isn’t with developers or their needs. It is hard to learn two different languages, TSQL & C# or VB, and understanding set based operations is a pain the bottom. I really don’t have any issues with the business and its needs. We need to create more flexible applications, faster to respond to changing business requirements. My problem is with this concept that by ignoring the database functionality it will suddenly, somehow, function better… It’s nuts.
Love it. And it applies to LinqToSQL as well. Or perhaps even more so.
Word is, Linq to SQL may be dead. That’s what I saw in Database Weekly:
http://feeds.feedburner.com/~r/AyendeRahien/~3/437709881/microsoft-kills-linq-to-sql.aspx.
Ya’ know, for years I have tried to stress to multiple development groups the need to have really, really competent T-SQL developers to handle all the data access layer to take care of the problem that you are referring to, which won’t be solved in the way that they are going about it. Most have not listened.
I can tell you though that I am with a company that has a group as I describe and it really has solved the problem. Now, the only problem is with me keeping up with all the requests that these people make. Most of them hurt my brain and when they do hit a performance snag it is usually not a quick fix type issue. Ouch.
Anyway, if it is any comfort, maybe they will let you provide input after this effort fails and you start for V3 of the application using a proper data access layer. 🙂
The thing is, I think nHibernate and ORM tools in general could work very well with the database. Let’s face it. Somewhere around 75-90% of all TSQL is boring, rote, CUD. Things usually only get interesting when dealing with that missing “R,” reads. If the developers would work with us to let us build effecient storage mechanisms and then only intervene in the area where queries might cause pain, but other than that, let them run with their tools, everything would work out better for everyone. It just requires working together. The DBA’s are not dictating, “THOU SHALT NOT RUN AD HOC SQL.” and the developers aren’t snearing “Databases? We don’t need no stinking databases.” Instead, each team focuses on what they do best and works to make the other teams lives as easy as possible. I’ve worked this way before with some teams.