In My Mind: Why the ORDBMS Idea Failed
Join the DZone community and get the full member experience.
Join For FreeSome 15 years ago, the idea of an ORDBMS (Object-Relational
Database Management System) was red hot, and I was very close to the
flaming hot center of that. I worked for Informix at the time, and Informix bought Illustra which was the hottest and coolest of the databases if it's time, hey it was an ORDBMS.
This was not a bad idea per se, and I got entangled with it and was
really enthusiastic about the idea and I spent a lot of time
evangelizing this technology. For Informix, this was as much market
positioning and a technical change, Informix went from being the cheap
redneck cousin to become the Gordon Gekko of databases. Before this, Oracle was the Big Market Leader, Sybase was the technology leader and Informix
was the price leader (no, I'm not talking technical realities, there
was a lot of good technical stuff to all of these, this is about how the
world at large perceived these guys). But Illustra and another Informix
project, XPS (aimed at the data warehouse market) was going to take
Informix to places it had never been before. Oh, the Billboard wars, the
day when Informix went past Sybase, those were fun days.
From a financial POV, Informix lost it, we already know that (read "The Real Story of Informix Software and Phil White" by "Steve W. Martin"
ISBN: 978-0-09721822-2-5), but that's not, in my mind, the whole story,
and I think that even though I think there are many good prspects for
an ORDBMS system, it's not really as generic as I figured it back then
(OK, I was wrong, I admit it, it does happen).
From a technical standpoint what went wrong was (this is my take on it,
by the way) that the cool ORDBMS features shoehorned into an aging
Informix RDBMS design ended up being largely the worst of both worlds.
That has been fixed, to an extent, in more recent Informix releases, but
not it's too late :-(
And from a conceptual view, this is also what I think is wrong with the
whole ORDBMS thinking. I know and love the traditional RDBMS model, with
a fixed number of columns and a variable number of rows, even if this
is a simple model, it works real well for data. It makes plain data easy
to visualize and understand, and this is also a well researched and
understood model for data. As for OO, then this has been thoroughly
researched, but the implementations and functionalities differ a lot.
Also, OO has a developer focues way of looking at data, for an
application, and Objects is a natural way of looking at things and makes
things easy, from an application POV. But representing data as an
Object is a different thing. Not a bad or good way, but different. The
Relational model also lends itself to building control structures for
data as it, assuming that the RDBMS is used in some kind of normalized
form, is representing data at a very low level, lower than what most
applications or end-users view data. And Objects are a way of combining
all this data into something that is more application centric.
So the ORDBMS systems turned non-OO enough to not attract the OO people,
and at the same time the OO features were non-Relational enough to make
the SQL-experts ignore them. (Like: "Why would I want a result set with
a variable number of columns?"),
And before I close this: Yes, I know there are many ORDBMS applications
out there, that works well and where the application utilize all the
cool ORDBMS features. Also, in Oracle and in Particular Postgres and
others, there are ORDBMS features that are developed. And inside
Postgres, the ORDBMS features is a building block for more than one
generic RDBMS feature. But for database people in general, ORDBMS is
something we don't see much of.
Published at DZone with permission of Anders Karlsson, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments