After having ranted about this in the CB and edan prompting me to make my ranting eternal by means of a post, I call rubbish on the three questions you actually meant to pose:

What is an Object Oriented Database?

What is Truly Object Oriented?

How do the two things relate?

I think that these three questions have no good answers because they are all three very ill defined, at least without further context.

For example, Smalltalk people call other languages "not Truly Object Oriented", if there are things in Other Languages that are not objects, i.e. you can't call methods ("send messages" in Smalltalk-lingo) to them. In that sense, Perl is not Truly Object Oriented, as you can't call a method on an integer. autobox is a hammer to solve this perceived problem. You also can't manipulate classes as if they were objects, which has a "solution" in the form of, for example, Class::Classless. I'm not convinced that these perceived problems are actual problems, but if you're talking to somebody in the Smalltalk camp, they will use that as a line of demarcation between Truly Object Oriented and Providing Syntactical Candy to Seem Object Oriented.

There also is no standard to what databases need to provide to call themselves "Object Oriented". Any database can be called Object Oriented, as long as you restrict what you call your objects to databases, tables, rows and indices. It is an ill-defined and much abused term like "XML databases". Perl has Class::DBI which provides a thin persistence layer for objects into databases, and thesetwo discussions pointed out to me by Super Search go much deeper into the problems and solutions of OODBMS. I don't see much use in these, because if you're going to store arbitrary objects in your database, you have a much larger problem as to what to do with these objects, and if you don't know about your objects, all you will be able to do with them is call a given set of methods on them, operating on them in an iterative fashion, instead of operating on them as a set, like traditional RDBMS do. Then, you are likely either well off using a tied hash to serialize your object data, or using Class::DBI, depending on whether you want to go the extra mile to define a database schema for your objects or just serialize them as blobs.

As I didn't come up with a favourable answer to any of the first two questions, the third won't be answered by me either, at least not in a constructive way - you can always map an "object" to a "data structure" and code that operates on it, like, say, a hash, and a set of functions that all take the hash as the first parameter. So there is not much sense in saying that only a Truly Object Oriented Language can interoperate with an Object Oriented DB. Perl also has enough of introspection and the eval statement so that you can generate classes on the fly, so as long as the database lets you in on the object format, you can create a suitable class for it. Whether that is what was meant, I don't know though.

I plan to print this out and keep it with me the next time I'm talking with someone and they tilt their head, furrow their brow and say, "But is it truly OO?", at which point I will smile broadly and leap into a fascinating but mostly pointless discussion of What OO Means Anyway.

I won't end up working there (yes, I admit, I did picture an HR droid with their Arts degree on the wall), but I'll know I had the Right Answer To An Ugly Question.

I find that the people who are so intent on OO are often the ones who have no idea what it means. They do know that it's a cool buzzword, hence favoured by HR drones, marketing droids, shiny project leaders and so forth.

I'm perfectly happy to split hairs with someone in a logical argument, but when I hear a body in a $1000 suit asking about OO, it's probably because they read about it in a brochure somewhere and they're trying to make an impression -- much as well educated Europeans a hundred years ago would drop English, French, Italian, Latin and Greek into conversation to casually convey the impression that they'd been 'properly' schooled.

My view of the world is more skewed towards a meritocracy, as misguided as that may seem. And, yes, Don Quixote is one of my heros.

Well, in perl someone could write a Class::AsObject module which injects methods like delete_symbol, create_subclass($name), add_field, add_method, and so forth into the UNIVERSAL namespace. These methods simply work as class methods, with the instance data sort of being the symbol table hash that the class takes up.