Dave Mc Cusker and Simon St Laurent on hierarchical vs Object Data Base-s.

Simon says: I'll admit that a few years ago, when I first encountered them, object-oriented databases (Object Data Base) seemed really cool. Instead of battling the differences between relational tables and object structures, I'd just be able to drop my objects in a box and pick them up later when I was done, not to mention query and manage them. It seemed great, except that the systems I could find were amazingly expensive beasts geared toward the enterprise, and it was early for Java (the only language I've built a lot of objects in) anyway. More recently, I've been cheering the return of a different but related style of database, the Hierarchical Database, for XML work. Hierarchical databases were hot in the early 1970s and continue to be used today, but mostly faded before the relational onslaught. Hierarchical databases share some structure with object-oriented databases, but don't really (need to) have a notion of objects. They tend to be a nice fit with XML's hierarchical element structures.

Dave says Normally I call [IronDoc] a structured storage system. Same thing. It's not an Object Data Base, because I see no need for object-based. I think class-oriented persistence frameworks (Transparent Object Persistence) are tedious and ugly. Instead, I like a system that presents mechanisms for persistence. Then you can build whatever you want from graphs and hierarchy. You can always add object-based framework layers on the very top. But I think it's idiotic to lace all data storage with code dependency. Why would you tie data integrity to fragile class and object issues? (Paul Snively goes on to note that he's settling for MetaKit while waiting for [IronDoc].)

User Options Recent Changes Help Page