Object-oriented database management systems (OODBMS)
There seems to be a fair amount of confusion about object-oriented database management systems (OODBMS). Let’s start with a working definition:
An object-oriented database management system (OODBMS, but sometimes just called “object database”) is a DBMS that stores data in a logical model that is closely aligned with an application program’s object model. Of course, an OODBMS will have a physical data model optimized for the kinds of logical data model it expects.
If you’re guessing from that definition that there can be difficulties drawing boundaries between the application, the application programming language, the data manipulation language, and/or the DBMS — you’re right. Those difficulties have been a big factor in relegating OODBMS to being a relatively niche technology to date.
Examples of what I would call OODBMS include:
- Intersystems Cache’, the most successful OODBMS product by far, with good OLTP (OnLine Transaction Processing) capabilities and a strong presence in the health care market. Although it was designed around the specialized MUMPS/M language, Cache’ happily talks Java and SQL.
- ObjectStore, a well-pedigreed startup a couple decades ago, which wound up focusing on complex objects in markets such as computer-aided design. ObjectStore was eventually sold to Progress Software, which is positioning ObjectStore more as a distributed caching system than anything else (Amazon was an impressive reference for that use case). That said, Progress’ ObjectStore business is small, as is its ObjectStore level of effort. Both Cache’ and ObjectStore were at some point unsuccessfully targeted at the XML database market.
- Part of Workday’s technology stack. Very-well-pedigreed SaaS (Software as a Service) application vendor Workday decided to go with what amounts to an in-memory OODBMS. This makes all kinds of sense, and is a lot of what rekindled my interest in object-oriented database management.
- Objectivity, also from the 20-years-ago generation, and a poster child for the “DBMS toolkit as much as a DBMS” issue.
- McObject Perst, an embeddable memory-centric OODBMS.
- Versant. Actually, by now the Versant company has several different OODBMS; I’m not sure whether what it’s selling has much to do with the original Versant product. Anyhow, both the original and current Versant product seem to be positioned in OLTP. Versant has recently suffered from declining revenues, in license fees and maintenance alike.
- Forthcoming technology from Starcounter, in the area of high-performance memory-centric OLTP. According to my correspondents, Starcounter still needs to explain how its technology is different from what Versant and ObjectStore introduced 20 or so years ago. Interestingly, while ObjectStore shines as a distributed system, Starcounter’s developers have consigned scale-out to the “too hard to bother with” category.
- Gemstone, which seemed to be on an ObjectStore-like caching track until it was acquired by VMware.
Arguably, OODBMS have all the benefits of document-model DBMS, but with different language bindings. And if you’re going to write in an object-oriented language anyway, those language bindings can seem pretty appealing. In particular, they might be preferable to fighting your way through object/relational mapping.
Other than the double-edged language sword, the main criticism of object-oriented DBMS is that they include a whole lot of pointers. Intersystems and others have shown that, even in a disk-centric world, OODBMS can have excellent performance in OLTP and tolerable performance in simple reporting. As RAM gets cheaper, memory-centric operation becomes ever more viable, making the pointers even less problematic.
Bottom line: If I were starting a SaaS project today, I’d give serious consideration to memory-centric OODBMS technology.
Comments
20 Responses to “Object-oriented database management systems (OODBMS)”
Leave a Reply
I think that many people want to know how you see the difference between a graph database like for example neo4j and an object database?
How about one stores objects, while one stores nodes and edges?
Curt,
The language bindings – or more accurately
embeddings – that make OODBMS so attractive
to developers for writing custom application,
also proved to be a major obstacle to market
penetration and were one of the reasons why
OODBMS never delivered on their promise.
Different programming languages represent complex
data objects internally in different ways – even
compilers for the same language, e.g. C++ may do
this! The net result is that a Versant application
program written in C++ for say, Sun and compiled
with Sun’s C++ compiler will end up storing data
in a Versant database in an internal format that
is different, and therefore incompatible with say,
IBM’s C++ compiler.
Applications written for an OODBMS on platform X
oftentimes are not compatible with the same app
on platform Y! This is one of the factors that
made OODBMS unattractive to commercial ISVs,
and led to the marginalization of OODBMS in the
broad commercial software market.
Spoken from first hand experience, as I once
worked at Versant!
Dan Koren
Dan,
Thanks!
If the OODBMS runs in-memory, however, with persistent storage being used just for safety, then a lot of those objections could be lifted.
Also, if you’re a SaaS vendor, you don’t need much platform portability anyway. 😉
Dan,
You wrote that objects would end up different depending on the language used. This is true only if your database allows you to serialize/deserialize objects. Our Starcounter database does not allow that. The integrety of our graph tuples is not governed by the language and can thus be shared between any language including functional ones.
Regards
Joachim Wester
I’m old enough to believe in the hype cycle (http://en.wikipedia.org/wiki/Hype_cycle).
Consider the first wave of the PDA and smartphones of 1992. Then look at todays reincarnation as the iPad and iPhone.
The hippest social network developers are just starting using JSON path expressions in C# and Java. Wake up the dead and ask them to say, I told you so.
Just as the case with the PDA vs iPad. What is dead is:
1. Serialization (bad idea)
2. Tight coupling to the language (bad idea)
3. The 90s implementations (most of them)
4. Trends. You can’t call the iPhone a PDA.
You can’t call CouchDB a slow ODBMS.
“Starcounter’s developers have consigned scale-out to the “too hard to bother with” category.”
Be ensured that we are working on scale-out.
Joachim/Jack,
OK. NOW you’re beginning to sound like you’re actually building something better and new. 🙂
to Joachim:
I actually stated something more than you attribute: even objects created in the same language, e.g. C++, could be different as a
result of different compilers being used!
In Versant and other ODBMS of similar vintage, an object compiled with say, Sun’c C++ compiler would look different in storage than the same object compiled with IBM’s C++ compiler.
This has nothing to do with serialization or
deserialization. AFAIK Versant did not serialize/deserialize, storing all objects in their native formats as determined by the compiler. Versant provided language bindings and libraries for multiple platforms and multiple compilers.
Regards,
dk
to Curt:
Compiler dependency is irreducible and cannot be completely eliminated — run in memory or not.
The only way I know of to relax the language dependency of ODBMS systems is to build the system on top of a common object system that is shared by several programming languages — such as Microsoft’s .NET/CLR.
Regards,
dk
As some of you have mentioned Versant and our products:
Yes, we do have several ones: starting from embedded db4o over FastObjects to Versant Object Database. All of them serve different purposes, as we believe that different problems might need different solutions.
Speaking for VOD in it’s current Version 8.0.1: we offer APIs for different programming languages like C++ or Java. And we have a client for .NET where you can use the programming language of your choice, as the implementation is based on the underlying IL code.
All of our APIs use the same server implementation with the same underlying schema.
Of course, you can use the same database from different flavored C++ clients like IBM, Sun, gcc or Microsoft simultaneously.
Hope that helps,
Andreas Renner
Probably worth mentioning that for Versant, not only can you use different flavors of C++ clients to the same database, but it is also possible to access that database with our Java bindings … even though the model is defined with C++, so there is some confusion here.
Also, there are low level access API’s which enable dynamic types. Actually, that is how we’ve written all our database tooling in Java which accesses databases created and used by .NET, C++. Java applications. Though dynamic types exist in C++ as well.
Sometimes it helps to make a distinction on what an object database delivers within the context of terms used to describe NoSQL technologies.
Most of the latest emergence of databases used to help with today’s scale-out challenges are talked about as key-value stores. Even the “document stores” fall into this category as well, though they provide an extra layer of meta data extraction so you can query the values.
The Versant object database can be thought of as going one step beyond key-value … key-graph.
Versant allows you to partition keys ( any user decided root object )across an elastic cluster of database nodes. However, under those keys are full object graphs, not isolated blob documents or “values”.
By doing so, there is no requirement to write layers of code to manage relations between types in the graphs in the way necessary using an ordinary key-value store or document store. Any object in the system can be the target of a query, it is not necessary to explicitly extract a meta data layer.
Even further, these graphs are not isolated, they can have refences to other graph’s objects beneath other keys. In fact, objects in those graphs can reference any other object in the entire cluster and those references are automatically resolved for you at runtime. Updates to these graphs can be fully transactional if desired, not only accessed in a CAP manner.
Hopefully this helps shed some light on the power of the object database.
-Robert
@Dan
“I actually stated something more than you attribute: even objects created in the same language, e.g. C++, could be different as a
result of different compilers being used!”
This might be true for some databases. In many modern NoSQL and OO databases your data is not affected by the language you use any more than it is in Oracle. I.e. if you use C, Java, C++, C#, Ruby or any other language of your choice has no relevance to how data is modelled or stored.
[…] 我建议SaaS供应商采用面向对象数据库技术 […]
is it possible to include c++ template feature in oodbms?
Dear sir,
i want to know about concurrency control in object oriented database.please send any material
@keerthu
Please let meknow your email and I will send you some docs for your reference.
I am sumit kumar. Iwant to learn database manegment systm n want to know deepely about dbms.
a oracle é um SBDOO?? qual o melhor SGBDOO PRA GRANDES EMPRESAS?
[…] Object-oriented DBMS never got off the ground, Intersystems Cache’ eventually excepted. The core problems were: […]