From: Steven Balensiefer (alaska@cs.washington.edu)
Date: Mon Apr 26 2004 - 10:11:22 PDT
Of Objects and Databases, a Decade of Turmoil
This paper provides a retrospective look at the development in the database
community relating to objects during the decade 1986-1996. In addition, the
authors make projections about the facilities and types of object related
commercial solutions that will be available in 2006.
The introduction of the state of objects in 1986 described four major areas
where research was progressing. All areas were attempting to provide new ways
to incorporate object-oriented programming into the database world, and to
possibly apply database principles to more complex data. I was particularly
surprised by the idea of research into persistent programming languages.
Perhaps I misunderstood, but it sounded like the goal was to enable a
programmer to easily specify the disk storage details of objects he created. If
that's correct then I would expect portability to be a tremendous problem,
because the compiler would need to know not only the instruction set, but also
the details of the disk itself, dma capabilities, os support for such, and the
bus access protocol. I suppose there could have been subtle techniques to
abstract away these details, but I still thought the concept was questionable.
When the authors moved to assessing the current state of objects in databases
as seen in 1996 they noted that both persistent languages and database
toolkits been largely ignored by the commercial world. I thought the comment
that the database toolkits required a high level of expertise to use
effectively was particularly telling. Often in systems, the designer takes
great lengths to provide the user with the freedom to make application specific
optimizations. It's usually swept under the carpet that users are purchasing
solutions because they are unable to make the design decisions, or do not want
to spend the development time of creating a custom solution. This is one reason
why application-specific microprocessors have fallen out of favor in the
architecture community.
With only a passing knowledge of the "State of the Art", it seems like the
authors were correct in projecting the continued success of ORDBs. To my naive
awareness, it seems like the best way to go, because traditional data is still
supported completely, but extensions are available if the need should rise. I
thought it was a telling critique of OODBs that engineering applications were
the only described application space. The number of companies who do the kind
of design work necessary to justify enterprise-level OODB sytems is small.
Therefore, these systems have a defined niche for the time being, and further
advances in ORDBs are likely to encroach even there.
I thought it was interesting to read this paper and hear not only about the
ideas that actually worked, but also the ones that were discarded. We still
have two more years, and I think it would be interesting to see a further
retrospective where these authors evaluated their projections for 2006 against
the actual developments.
This archive was generated by hypermail 2.1.6 : Mon Apr 26 2004 - 10:11:24 PDT