Attention: We have retired the ASP.NET Community Blogs. Learn more >

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.

9 Comments

  • Sadly I have to disagree - at least in part.

    You're spot on in terms of development - SQL doesn't quite cut the mustard, and is flawed from an object oriented perspective.

    But what if you want to do something with your data? like look at relationships of facts to other facts? Querying objects for that kind of information would likely become very expensive. It likely would also be very hard to organize some of the relationships that make SQL so valid and useful.

  • Looking at the relationship of facts to other facts is exactly what the relational model was intended to do. I recommend reading C.J. Date's Database in Depth where he talks about the original intent compared to what SQL does. The relational model addresses relationships between facts very well, SQL does not.
    The relational model as originally defined has nothing to do with performance, and that's why it is important to seperate the logical model from the physical model. However, SQL coupling the physical layout to the relational model, gives this idea that somehow the layout of the relationships effects performance. It shouldn't. An optimal physical layout should be able to be derived from the relationships which might be a completely denormalized database. However, this shouldn't be the way you design your relationships.

    Objects are simply a view of the facts that you have defined. The relational model, as originally defined, would allow for much more seamless O/R mapping and data analysis, since views in the relationship model itself are fully updateable. In fact, tables themselves are not distinguishable from views in a system that implements the actual relational model, not a SQL based version of it.
    Note, I'm not saying that SQL should be based on objects. I think 100% the opposite. The database should only be a collection of facts, nothing else. No objects, no tables. Just facts and relationships to other facts.


  • If only they'd listened... I think it's time that someone rebooted everything.

  • It is sad to see so many smart people debating on a wrong concept. RDBMSs are right on target to provide what they were designed to do (SQL server/Oracle/DB2) etc. It is just an evolution path they are following just like any other technical production/framework. However most of the development community members are proficient in certain technologies and not all but very few are candid enough to admit so we all want the platform (we are proficient in) to support everything. Thus came the ORs. ORs do solve some Rapid Development Issues, they do improve the development life cycle for most of the simple technical solution, the problem starts when simple solution is extrapolated to complex solutions and that causes a disaster. I think we should

  • I think it is the right place here. I see that now, it is too late , but i hope the massage it is good.

  • I have to agree SQL is flawed but it has it's importance too. Like checking out relationships of facts is great with SQL. I guess it all depends on what you need to do.

  • Entity framework right problem wrong place.. Reposted it :)

  • Every word in this piece of work is very clear and your passion for this topic shines. Please continue your work in this area and I hope to see more from you in the future.

  • Bravo, you were not mistaken :)

Comments have been disabled for this content.