On my drive home this afternoon I listened to episode 102 of Hanselminutes, where Scott talks to Mike Pizzo from the ADO.NET Entity Framework team.

Mike's description of the EF was great - it was a much better show than the recent .NET Rocks! episode on the same topic. Something that Mike said, however, really caught my attention. He talked about the impedance mismatch between the way we code our objects and the way relational databases store data. The fact that relational databases just have tables and constraints, and don't have concepts for relationships, inheritance etc.

It's an old problem, and one that countless ORM (object-relational mapping) products have tried to solve over the years. The Entity Framework is just the latest in a long string of attempts from Microsoft to make object-oriented coding against a relational database easier.

But is Microsoft attacking the problem from the wrong end?

Is there a reason that SQL Server, or (better still) a new database product from Microsoft, couldn't introduce concepts like relationships and inheritance? I mean, I know that such concepts aren't supported by standard SQL ... but is that a big deal? Unless I'm writing a product that can support multiple database back-ends, do I really care if the access method for the database is standard SQL?

What if Microsoft were to bring out a product whose only means of access, rather than SQL, was via the CLR? A database with object-oriented properties like inheritance and relationships, but also relational features we've come to depend on like indexes and constraints? Wouldn't that be worth something to all us .NET developers?

I know there are object-based and hierarchical databases out there, but really Microsoft is in the unique position of being able to bring such an animal into the mainstream, with full .NET support. Is it too much to ask?