Kevin Wilson asks:
 
>I'm curious to know if HP is working on or plans to
>develop an Object Oriented Database for any of it's
>platforms.  Has anyone heard anything through the
>"grapevine"?
 
Five or six years ago, HP tried very hard to sell you, if you would listen,
their new OODB database. I now don't even remember what it was eventually
came to be called, but they did describe it in their sales pitch (in the
interest of full disclosure), as a "real MIPS-burner." And if you didn't buy
the database outrightly, they tried to recruit you to write class objects for
the database. If HP sold more than 10 copies of their OODB, I would be
surprised (astounded, actually); the going price was $100,000, regardless of
CPU size. Nor do I believe that any instance of the OODB was ever put into
even a trial production mode.
 
Not every idea that comes down the pike is necessarily a good idea -- and
OODB is probably in that category, regardless of its specific implementation.
The OODB that HP put together was constructed as a shell on top of ALLBASE
using the SQL interface, thus it imposed a significant additional overhead on
the simplest queries.
 
Now that IMAGE/SQL exists, the same OODB shell could have been put on top of
it, too -- but that would represent a fourth access level in a heirarchy of
various access methods to precisely the same data: (i) direct file access
(which is the superior method for very high-speed MR-NOBUF serial searches),
(ii) intrinsic level access (which is the superior method for chained reads,
puts, updates, & deletes), (iii) SQL level access (for the utilization of
semi-standard client/server access methods), and (iv) the OODB level access.
As you access your data at each higher level, you incur increasingly
substantial overheads, meaning significantly higher impacts on other
processes, with longer response times, and the requirement of increasingly
more powerful machinery.
 
The OODB phase came and went with HP 5-7 years ago, as it did with much of
the industry -- and didn't last much more than one or two years. But during
its time, it was as trendy as anything you might hear recently. I am
unfortunately becoming jaded as I grow older. I now have come to believe that
if the method adopted isn't simple, it won't be reliable in the end. And if
it isn't simple, it certainly won't be efficient. And if it isn't simple, it
may never be gotten to work, even as a trial system, much less as a
full-scale production process.
 
Well-implemented databases may be a little boring, but there is ultimately no
substitute for efficiency and craftsmanship, characteristics that the basic
IMAGE database structure has always exhibited.
 
Wirt Atmar