One of the more rewarding recent trends that I’ve been observing in the development space has been the acceptance, grudging though it may be at times, that different development challenges may in fact necessitate different tools and technologies. Not new tools, necessarily, but different tools. The most recent example of this is the IBM/Zend deal, but this recognition can also be seen driving other developments such as the overwhelming preference from developers for REST based web service development. The developers themselves are light years ahead of the vendors that support them in the realization of this truth, but give them time and I’m sure the technology purveyors will get there. The winners will, anyway.
But the larger issue, at least for this analyst, is this simple and often asked question: what’s next? What does this trend portend beyond the world of language preferences or web services approaches? Well, as far as I can tell, the next major area affected will be the data layer.
Now before we get there, let’s have a quick reality check. How many of you in reading the sentence above did the mental substitution of “relational database” for “data layer?” I know I probably would have, and I’m guessing most of you have as well. How could you not? Over the past few decades, persisting data for the applications that needed it meant a relational database. Sure, the names may have changed and vendors may have risen and fallen, and there was an exception or two such as Sleepycat’s Berkley DB, but pretty much universally when people talk data persistence they mean “relational database.” Ok, maybe not in a zSeries shop, but pretty much everywhere else.
This virtual tunnel vision is certainly not due to a shortage of other options; vendors like iPedo, Sleepycat, and Software AG have been around for years and have offered a different way to tackle certain development challenges whether that’s XML, non-relational storage, or integration. But as with Windows on the desktop, the inertia of relational data storage as the de facto standard has been remarkable.
But I’ve been hearing a bit more grumbling lately (due perhaps to the invasion of simplicity elsewhere in the dev lifecycle?) from the development community that relational databases may not in fact be the answer to every problem. Many of them, perhaps, but not every problem. What are some of the shortcomings? Well, I’ve been recommending that everyone take a look at what Google’s Adam Bosworth had to say in a blog entry here and a Gillmor Gang session here. It is startling, when you take a step back, at how difficult it is to use relational databases to solve non-trivial problems.
It may well be that the relational vendors can address some of the issues Bosworth and others have described, but I also see in the difficulties he cites opportunities for vendors with different approaches. I found, for example, the decision by the Mono team to ship DB4Objects with their package interesting not just because it augments the runtime and libraries with an out-of-the-box persistence layer, but also because that persistence layer is object oriented. Christof Wittig and the gang from DB4Objects may position this as a solution for prototyping, but as I told him when we spoke at LinuxWorld, anyone who’s developed for any length of time knows what happens to prototype datastores. More often than not, they become production datastores because if they work, who’s got time to replace them?
But the acceptance is merely a symptom of a larger trend; the willingness to look at RDBMS alternatives. After all, if object oriented databases can find acceptance, what of XML datastores? Might there be a sizable population of developers out there that would prefer to work with their XML natively, without shredding it and cramming it back into non-fitting and rigid tables? The answer’s clear from the conversations we’re having. For example: one of the roles we try to play as analysts with contacts both in the vendor community and the developer side is facilitation; technology match makers if you will. When we asked the folks behind one project if they’d like a peek at some XML technologies we’d been discussing with a vendor client of ours, the answer was an immediate yes. This reaction was neither a surprise nor a fluke: the interest is clearly real.
Whatever the technical basis, I think developers are beginning to loosen the relational shackles just a bit, to the point that they’re permitted to at least explore other technical options. Whether they’re XML, object-oriented or just really sophisticated filesystems is ultimately besides the point – it’s the fact they are actually meriting longer looks that matters. From a developer’s perspective, it’s about projects that can choose the technology that works best for their needs. Maybe that’s relational, but maybe it’s not. Been a while since many have had that choice, and it’ll be fascinating to see what people do with that freedom.
