Object Oriented Database - why most of the compani

Question

I am pretty new to programming(just finished University).

I have been thought in the last 4 years about Object Oriented development and the numerous advantages of this approach.

My question is

Isn't it easier to use a pure Object Oriented database in development applications?

Why Object Oriented database are not as much diffuse as relational?

From my point of view makes sense to use OO database, the latter will avoid the numerous construction necessary for the mapping of complex objects on the tables.

Answer 1

One reason why adoption of Object Oriented databases is so slow is that are aren't many scalable OpenSource alternatives. For RDBMS there are for example MySQL (Oracle owned now), PostgreSQL and many more.

Another problem is that at least for Java the standard APIs for RDBMS access JDBC and JPA for the ORM part have bigger companies behind and are better known. JDO for object oriented database access is a standard, but not as popular.

Object Oriented databases have in most cases a stronger API or language lock-in than RDBMS, which is another reason why bigger companies with multiple platform and language investments stay with RDBMS.

For me personally popular OpenSource OO databases would be a reason to invest more time into trying them out.

Answer 2

There are no advantages to using this approach when you already have a relational database already that is many gigabytes in size is storing 20 years of data already and has hundreds or thousands of tables. This is the real world of many business applications. Databases are used for a lot more than Object mapping of your particular application. The database will still exist long after the applications you write are gone. Bite the bullet and learn relational databases as they aren't going away any time in the next 100 years.

Answer 3

Another issue is language support. What about the languages that aren't object oriented? A good database needs to be accessible by everyone, no matter what language. Thats why a lot of language specific databases fail, because their market is only people of that language.

There is also the migration factor. MySQL's biggest users are long time users. Migrating to a completely new database system with a completely different fundamental design with a large existing one would be very expensive and give little reward.

Answer 4

As you state, you're fresh out of college and have just been intensely indoctrinated in The One True (Object-Oriented) Way. If on the other hand you had learned declarative programming, database design, and set theory, you'd realize that the relational model is a perfectly adequate approach, well grounded in theory, while OO is a more pragmatic approach that was invented mostly in industry rather than academia. As it happens, most interesting research and development on database problems is being done by people with more of a math background, for whom the relational model is the more natural way to work with data. As a result, RDBMSs tend to be more stable, scalable, and trusted than their object-oriented counterparts. Object-oriented databases, much like XML, are often used in an ill-advised attempt to make data conform to the programs that use it, instead of the other way around.

Answer 5

Apologies for not being able to add this as a comment in the place where it really should appear.

But the following constitutes a personal attack on me, and I invoke my right to respond.

Though I agree with you in practice, I disagree with you in spirit, I think you're the one who's been brainwashed to believe that set-based is the only way (maybe I'm putting words in your mouth).

FWIW, I have most certainly NOT been "brainwashed" into what you might probably call "the relational religious belief". Brainwashing is when some tutor says something, and the student blindly and brainlessly accepts that as the sole truth without any form of critical thinking. In fact, I have even never been taught the relational model. In fact, I have had to discover all that all by myself. It is a recorded matter of fact that I have expressed severe criticisms toward Date's opinions on the subject of view updating. (correction : "was" a matter of recorded fact. The page seems to have been removed from the site where it was published. Probably has everything to do with the fact that Date has indeed abandoned the view updating position I criticized.)

So I think I have every reason to say that any claim that I ever let myself be brainwashed, is outright propostrous. You are free to think as you please, but if you publicly express any gratuitous and based-upon-nothing personal opinions, I hope you are also enough of a grown-up to see them rebutted by facts and admit it.

The reason why hierarchical and network models have been superseded by the RM has been amply documented in entire libraries full of books on the subject. I invite you to inspect those carefully.

As for "key-value is taking over the market": you are completely free to take "the market's most common opinion" (that is: the mediocre majority of too-lazy-to-think-for-themselves fools who are quite happy to let themselves (and their opinions) be led by the Ellisons and Gateses and Jobses of this world) as the main yardstick for what is valuable and what is not. I personally find that a foolish thing to do, but that's only my personal opinion. I copy-paste here some observations made by someone who faces the horrors of EAV and Key-value almost every day of his professional life :

I work on an application that uses the following "EAV model" (at least, the "EAV model" as I understand it) for many, but not all, logical tables:

R1 {EAV_RELVAR_NAME*, ... }
R2 {EAV_RELVAR_NAME*, ATTRIBUTE_NUMBER*, COLUMN_NAME, DATA_TYPE, ...}
R3 {EAV_RELVAR_NAME, ATTRIBUTE1, ATTRIBUTE2, ATTRIBUTE3, ..., ATTRIBUTE50}

In which one might see the following values:

R1 { {'STATE_CODES'} }
R2 { {'STATE_CODES', 1, 'STATE_NAME', 'CHAR(30)'} ,
     {'STATE_CODES', 2, 'STATE_CODE', 'CHAR(2)' } ...}
R3 { {'STATE_CODES', 'ALABAMA', 'AL'} ,
     {'STATE_CODES', 'ALASKA',  'AK'} ...}

Basically, "EAV relvars" are created/altered/dropped with inserts/updates/deletes into R1 and R2 (as compared to DDL). This is a trimmed down version of our overall model: there are additional columns in R1 and R2 to specify eav-primary-keys, eav-foreign-keys, business rules, etc... all enforced by procedural code embedded in the "one true front end" of the model.

This morning, I was privy to a 20+ man-hour ordeal that resulted when System A thought CODE_XYZ would be in ATTRIBUTE2, but System B actually defined it into ATTRIBUTE3... I had to laugh at the fact that I was half-listening to the conversation, and half-reading this group's discourse on EAV.

Last month, I got to put in an emergency update (16 man-hours plus "bad marks" for the application) to change ATTRIBUTE16 from 'MAY 2010' to 'MAY-2010' for 430 user-entered data points.

About 5-10% of our code releases are accompanied with "Monday-morning runtime-error cleanups", because EAV_RELVARs were not coded into R1 or R2 identically in production as was done in test/development (both application code and DDL is migrated with strict-versioning software control... our EAV model is not tied down to such bureaucracy as it "allows" developers to set up their EAVs autonomously in dev, test, and prod.).

Last year, I spent a solid 3 weeks tuning replication software exclusively to deal with the lack of a primary key on R3.

I once had to apologize for the inability to put an index on ATTRIBUTE4 of EAV_RELVAR_NAME_x, as it was messing up the performance of a different program that used EAV_RELVAR_NAME_z.

Two years ago, after several years of sinking hundreds of hours perpetually tuning complex queries which needed to join to R3, I finally spent 3 months splitting R3 into hundreds of physical partitions (one per EAV_RELVAR_NAME), in order to give the DBMS optimizer the stats needed to see that there were, e.g., 50 'STATE_CODES' and 200,000 'LOCATION_CODES'. I was congratulated for the ingenious solution, though the irony was missed on everybody when I pointed out that, with this change, there would be a new policy whereby adding a new EAV_RELVAR_NAME would entail running a script which added an associated partition to R3 (yes, with DDL).

My clients want a new front end for loading data into R3 for one of their EAV_RELVAR_NAMEs (while enforcing all appropriate constraints and security), and they want to know why it will take 4 months to build.

I often point out that I could rewrite the entire EAV system in a fashion that was superior in every way, using the dynamic-DDL against data dictionary instead of DML against R1 and R2, but I'm always informed that we're "committed" to this approach (there was a 7-figure up-front expenditure to build it, and we'd have to rewrite 98% of our codebase to switch to stand-alone tables), and that the ends don't justify the means.

If you really believe that such scenarios are an improvement over the RM, then by all means go ahead. Don't blame me for how much it hurts when you finally bang your head into the wall.

Answer 6

Having worked for an Object Oriented Database company in the past (www.objectstore.com) - and currently - I think I have a fair insight on what makes them great, and what makes them no-so-great.

Great:

No object-relational mismatch. If you want to store object x in memory to a persistent store, ObjectStore can do it with near-realtime guarantees. Our product has been used by many companies to meet brutal time requirements that would be tough with relation databases or ORM engines.

No object-relational mismatch - you develop in objects, you think in objects, you store in objects.

No-so-great:

ORM: Object relational managers have pretty much made Object databases irrelevant

Schema evolution: Change a class to add a field, and now you have to morph an ENTIRE database. ObjectStore has gotten smarter about this over the years, but it's still a pain point for many OODBMS.

Bad:

Tool support - this is what made OODBMS a non-starter for most places. Everyone today can take Crystal Reports or Access or Excel and churn out bucketloads of reports. With an OODBMS, you would have to build this logic through a programmer, and we all know how fast that's likely to happen when you need your budget report to take into account some xyz parameter that you didn't think of at design time.

Tools are why OODBMS failed in the marketplace. Not technical superiority or performance or language support (ObjectStore supports C++/Java/.Net and had support for COM to support any IDispatch languages like VB, Perl, etc.).

So I've said some disparaging things here, particularly about a product I really like. But ObjectStore is awesome at very specific tasks, but a poor choice for building a webapp. Though at one point, it was driving the inventory management backend for Amazon.com.