Object Oriented Database
Object Oriented DatabaseObject-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.
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 , anyway.
The remaining 20% benefit of an ObjectOrientedDatabase (as well as the syntactical improvements over SQL) isn't worth deviating from the relational/SQL standard.
ObjectOrientedDatabase 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.
And RubyLanguage 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 (RubyOnRails). 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? (yes February 2014 http://www.service-architecture.com/products/object-oriented_databases.html ) Maybe on WikiWikiWeb? A GoogleSearch came up with the following (alphabetically):
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.
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.
Verb Divas
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, PrevalenceLayer, ModernDinosaur, ObjectRelationalPsychologicalMismatch.
EditText of this page
(last edited February 19, 2014)
or FindPage with title or text search