About Databases

Seems like a lot of developers spend a lot of time keeping other developers away from databases these days.  In a perfect world, these non-DB developers would never leave the comfortable domain of business objects, web documents and other non-normal-formed artifacts, letting O/R mappers, data grids/clouds, distributed maps and other magic things do the work for them.  There are exceptions to this general rule of course (e.g. data warehousing), but in your typical modern OLTP systems, right or wrong this dynamic likely exists.

In the last decade both the web and open source movements have brought down many a sacred cow, but have done little to displace the Relational Database.  That said, I, like many others these days am wondering if cloud computing is the last piece that allows turn-key object persistence to go mainstream.  No disrespect to those technologies that claim/promise to do this today but nearly every application that I look at these days still has the tried-and-true RDBMS chugging away in the background.  And as long as that’s the case, there’s a relational data model somewhere as well as a DBA or two providing the care and feeding.

So what would define object databases “going mainstream” in my sense of the phrase?  This is something that may take more than one blog post to articulate, but here is a start:

  • Elimination of O/R mappers as we know them today.  In fact O and R should actually coexist as opposed to being two separate dialects.  After all, classes of objects oftentimes relate in a way that is very relational except that the objects aren’t necessarily tabular in look and feel.
  • A persistence lifecycle that is more object (almost document) oriented in flavor.  The chekout-edit-put lifecycle that is found in source-code control is a good start,
  • A query language for objects that everyone can agree on.  In fact, a good place to start would be SQL but obviously with extensions to handle the richness of objects. Perhaps something like: Select
    Class1.fieldX.subFieldY,
    Class2.fieldA.subFieldB[1]
    From Class1, Class2 Where Class1.id = Class2.foreignKeyId

Granted this isn’t entirely new and yes there are OODB’s but the key point here is to get enough people to agree on such language such that all of the predecessors mostly fade away (remember Codasyl?).

NB: This fading away may also apply to XQuery.  Object graphs and hierarchical document structures are not too much different such that a unified query language can’t serve both.

Okay, so that’s a start but not the last word from me.  This is quite a loaded set of concepts with a lot to consider.  So in the not-too-distant future, I will be picking up this thread again in this space as I think of other things and/or evolve my opinion.

Advertisements