Object-Oriented Database Management Systems (OODBMS's) are databases that store their contents as objects. They map very well to the object models of the programs that use them.
Drawbacks include indexing (sometimes you have to write your own indexing code; often retrieval performance is bad) and interworking with non-OO company-wide systems. On the upside, the object persistence is easy to program, and complex data objects are surprisingly natural.
Price is also high at the time of this writing (ObjectStore
(?) costs around three times what the already-exorbitantly-priced Oracle 8i does). Alternatively, see OpenSourceObjectOrientedDatabase
In the general sense, an OODB is a NavigationalDatabase
... with methods.
- Many of them called OODBMS don't support methods.
Alternatives to an ObjectOrientedDatabase
include a PrevalenceLayer
, a RelationalDatabase
(by using ObjectRelationalMapping
), or a HierarchicalDatabase
(e.g. a filesystem).
Why haven't ObjectOrientedDatabase 's become popular?
I think the reason is that ObjectOrientedDatabase
is an oxymoron. A database, by definition, is a base of data
- it allows you to query it, index it, and revert it (transactions). All of these properties depend on dead, static data (try indexing a true method) - data that is the same no matter how many times you look at it. Objects, on the other hand, do the exact opposite - they hide the data under behaviors, which can vary depending on hidden things (information hiding), hence precluding queries, indexes, and transactions. In order to hook up your objects to a database, you need to do 80% of the work of an ObjectRelationalMapper
The remaining 20% benefit of an ObjectOrientedDatabase
(as well as the syntactical improvements over SQL) isn't worth deviating from the relational/SQL standard.
is not an oxymoron, and what database actually is is defined by what it can do and what it contains, not by some arbitrary definition that focuses on popular aspects only. If database contains "dead static data" only, what about the stored procedures? Triggers? Database contains data, but it does not have to contain only data. A simple, common sense to think what ObjectOrientedDatabase
is would be e.g. take Versant's approach: db stores objects and indexes them according by their public attributes. And you do not have to violate information hiding at all to get them: you could index on public attributes only, or on values returned by getters (like typical java getters). I don't see how finding accessing a public "x" attribute of live in-memory "new Foo()" object is not violation of information hiding, while searching for the Foo class objects in database and bringing them into memory from "hibernation" in ObjectOrientedDatabase
and then accessing their public "x" attributes would supposedly be the case of violating information hiding. Whether you hold objects in memory or on disk seems orthogonal to me to the issue of information hiding in objects. That's "just" a performance consideration, not enscapsulation or representation issue.
On popularity issue: there's a number of concerns here. 1. there is no object query language that would be both *standardized* and reasonably small to be *implementable* (practical, in short). 2. reason 1 results in lack of people with ObjectOrientedDatabase
querying skills => companies are unable to find people that would realize the benefits of ObjectOrientedDatabase
and so they don't use OODBs. 3. premises 1 and 2 result in lack of good open source ObjectOrientedDatabase
=> there is no place to learn ObjectOrientedDatabase
query language that would be widely applicable (that is, beyond one's personal interest) => premise 2 is reinforced.
It's also worth noting that OO DBAs are a lot harder to find than relational DBAs.
programmers are a lot harder to find than CobolLanguage
programmers. It's a SelfFulfillingProphecy
- a function of market penetration, viz. CrossingTheChasm
. (See also CrossingChasms
, a large pattern language that describes how to connect an object system to a RelationalDatabase
Ruby is open source, it is widely available and it has KillerApp
). Therefore, soon RubyLanguage
programmers will soon be more abundant than CobolLanguage
programmers. OODBs suffer for lack of equivalents of MySQL and PostgreSQL: it's chicken and egg dilemma, you don't use ObjectOrientedDatabase
bc you haven't learned it and risk a lot if you learn vendor-specific OODB (skills unportable between employers), and since few people learn OODBs, they don't get used.
Is there an up to date list of ObjectOrientedDatabase
vendors somewhere? Maybe on WikiWikiWeb
? A GoogleSearch
came up with the following (alphabetically):
(feel free to properly wikify these names if pages already exist for them, remove ones that are not relevant, and add ones that are missing).
Q. What are the differentiators for each of the vendors and their products?
A. The differentiators are probably the targeted use cases, scalability, product maturity, architectural philosophy, API, and of course, cost.
Is there a clear definition of what an OODBMS is? Or at least a list of guiding principles? BertrandMeyer
seems to suggest that OO is against the concept of DBMS's to begin with. There is talk that the concept of a database violates encapsulation. In this view OO is about behavior, not data, and you access data through behavior wrappers(methods). "Naked attributes" violates some definitions of encapsulation.
It seems one has to buy a book in order to make a bulleted list of requirements. That smells.
See also "The Object-Oriented Database System Manifesto" (at http://www-2.cs.cmu.edu/People/clamen/OODBMS/Manifesto/htManifesto/Manifesto.html).
- What's smellier is that each book would probably result in a different list.
There is still no agreed-upon definition or clear characterization of an OODBMS. It's difficult to judge the merits of one without a stable definition or feature set.
One of the problems with the idea of OODBMS is that the activities on objects and collections of objects is not standardized. In RDBMS and most prior databases you generally have a standard set of DatabaseVerbs
that all records and all tables respond to in the same fashion. It's a form of InterfaceFactoring
. In OOP philosophy, each and every object is generally considered its own independent
state machine with its own behavior. Any sharing of interface or behavior commonality is purely voluntary and thus inconsistent. This is against the idea that InterfaceFactoring
is important and useful; it's essentially anti-database. Having a standard set of collection-oriented operations does not preclude additional custom behavior, I would note. Custom behavior is fine, but one should be discouraged from reinventing the wheel if there already is a "close enough" standard operation. -t
Wow. It's rare I agree with Top, but I agree with Top. Quick, somebody photograph this moment.
For court evidence :-)
See also PersistenceEngine