In Beyond the RDBMS Sean references Martin’s post which in turn points us to a paper (gotta love the web in action) promoting “The End of an Architectural Era”. This paper advocates the complete rewrite (well trashing actually) of current RDBMS code in favor of specialized “engines”.
It’s an interesting read with some good points until I got to this:
Our current favorite example of this approach is Ruby-on-Rails. This system is the little language, Ruby, extended with integrated support for database access and manipulation through the “model-view-controller” programming pattern. Ruby-on-Rails compiles into standard JDBC, but hides all the complexity of that interface.
Rails compiles to JDBC? Now I’m questioning the the whole paper…
I hadn’t read that paper, but went back and they do actually say that. I wonder if it isn’t academic CS lingo for “code using the same patterns as JDBC is found underneath all the Rails abstractions”?
My interpretation is that they are just talking about the database abstraction layer, and are saying that you can express access to the database using a higher level object based approach, then the system “compiles” that down to the lower level semantics of JDBC-type access. Or in other words, in your application you don’t have to think in terms of raw SQL statements, Rails takes care of converting higher level constructs into SQL statements for you. Overall I thought the paper was very interesting, am writing some further thoughts on my blog at the moment.
Perhaps, but to a code-head like me “compiles” conjures up a very specific image. Maybe it’s an issue of semantics or a poor choice of words.
Yeah, I noticed that line in the paper as well. Like you, seeing such a glaring error caused a few cracks in my faith in Stonebraker the DB guru. Maybe as Sean and Peter suggest this is really actually such a deep abstraction that the actual semantic details don’t matter. I’m not so sure… my suspicion is that Stonebraker et al are so busy focussing on their core research that they don’t actually get a chance to really figure out how all this fluffy real-world messiness actually works!
This isn’t the only crack in the facade – see the recent MapReduce-critique kerfluffle for a much bigger example.
However, in spite of all this what Stonebraker says makes a lot of sense to me. The really interesting question is whether the “traditional” RDB platforms will simply be able to adapt to meet these new paradigms, or whether this creates an opportunity for new DB vendors to rise. Seeing how the whole object-relational thing played out, my money is on the former.
By the way, another application area which seems to be calling for a new kind of database architecture is – rasters! But that’s another blog post…