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.