switching tools

The impedance mismatch is between tools and compilers that manage different languages, which are elements of the same application.

Linq is LANGUAGE integrated query. In other words, while I write my C# or VB, i can write my data access code inline, and get the background compilation check direct against a data source. I have one tool and one language to learn, and a framework (which emits pretty optimal sql) talks to the database (or XML files, or roll-your-own) tier.

Other frameworks exist. As ever, Microsoft is not first to the market with the concept, but looks to me like they've learnt from others mistakes.

The Linq approach works when I have a database that belongs to a single application. In that case I like having the data access logic closer to the application developer, save them switching languages/tools and having more complex build and test processes.

If on the other hand I have a central database, used by lots of applications, I'm probably going to write stored procedures and ask the applications to call them; which, by the way, doesn't stop those applications using Linq. Just the ORM pieces.

If it's a really big database, like an AS400 with billions of records, I'm probably gonna wrap the logic in Web Services (or just a RESTful uri framework) where I can anyway, and ask people to integrate with those.