Entity Framework: Right Problem, Wrong Place
I was listening to the recent .NET rocks episode about the Entity Framework advisory council and it was interesting to hear the team's point of view and the problems they are trying to solve with the Entity Framework. They have nice goals, but there is a fundamental problem here that some of the original database gurus like C.J. Date make quite clear. SQL is flawed. It's not that we need a million object relational mappers or that we need to look at our databases in terms of objects. In fact, that's the opposite of what the relational model was intended to do. When E.F. Codd invented the relational model, he intended for the database to be a collection of facts with relationships to other facts... not a collection of objects. The relational model was supposed to provide a way to look at and work with these facts in different ways, but SQL and modern RDBMS's fall short of what they were supposed to do. Somewhere along the way, the original plans were lost. Instead of building a truely relational storage system, vendors jumped on the semi-relational SQL model. The SQL model ties physical structure closely to the logical data model, which is where a lot of problems start coming into play. This leads to the situations we've all seen where we need to denormalize the data model to get decent performance numbers. It seems to me that the solution to the problem should not start with mapping the data to objects, it should start inside SQL Server itself, transitioning from the flawed world of T-SQL to a true implementation of the relational model as it was intended, a world where the physical model is truely detatched from the logical model.