Database didn’t fail – MVC did

It's always a little bothersome when I hear that relational technology has failed. Sometimes it's a bitter-tinged screed, sometimes it's a relatively innocuous failure to understand what relational is about. There's this silly propensity to say that because the relational model is simple, it's primitive. You can't just write off E. F. Codd's Turing Award like that. (By the way, anyone notice how simple Turing machines are?) Codd recognized that despite formalisms like hierarchical databases, indexed files, and CODASYL, that era's very large databases were unreliable, rigid, and brittle. Database programmers and administrators found that they couldn't rework or restructure their data - and God knows that data exploration was unthinkable. He and Date solved it. But it wasn't by adding structure, it was by constraining the structure. I completely understand that relational programming is not natural, especially for those who were trained on procedural techniques. I know what it is like for programmers to encounter the relational model, whether through a persistence framework or through direct programming.  It's foreign.  But so were integral calculus, Karnaugh maps, and concurrent programming. And relational looks easy - until you get your twentieth interrelated table. That's where you found, like a chess player in the end game, that you had given up your queen fifteen moves prior without ever realizing it. How does it get this way? Is it the data? I believe the problem is that it's hard to think of the alternate uses for bulky and varied data. Your programmers ask, "how do I grab the fragistat for this hooziwhat?" and you realize that the hooziwhats have numerous overlapping fragistats and you have not put in anything to distinguish them. The programmers have brought you an entirely new way of looking at the same data that transforms how you understand it. It's the view that makes the difference. And consider what happened to Enterprise JavaBeans. A decade after they were championed and promulgated, they are denigrated and avoided. What was so wrong with them? It was unnatural to think of the composition and reuse patterns they suggested. They were "too hard." We're talking very strongly MVC-patterned objects built by known and proven experts with a lot of collegial input. The problem was not that the pattern was bad, or crippled by the painful horror of mass object instantiation, or even the unhappy confluence of Factory hackery with the novelty of classloaders. It was that the programmers using EJBs did not want to understand or use the model-view-controller paradigm, and the EJB Query Language didn't motivate them at all. You only build a query language to support alternate uses and retrievals of data. You only use it to build views. So it seems to me that what is foreign is not nearly so much the relational model, but the model-view-controller approach which you must take to use your relational DB, whether you are using an MVC framework or even Hibernate-ish plain objects. It's a conceptual hurdle that we pretend isn't even there. "MVC? It's been around since Smalltalk in the 1970's!" we think, but that doesn't mean that people are taught it, or that programmers learn it. In many ways, the worst failure of the Object paradigm is model-view-controller. Not because it is inferior - to me, it's one of the most valuable and crucial patterns available for software development. No, MVC has failed because it went from "too risky to try" to "old hat" without enough people trying it.