Oh goody, the tried and true, 'fast but inflexible' idea of using just serialized objects instead of relational datastores has a new name:Object Prevalence. To be fair, there's a consistent API to define the way the serialization is used, but it IS just serialization.
The tradeoffs are the usual ones: No cross object queries. No real transaction support (well, you can use a transactional datastore that is non-relational (i.e. what people do using Berkeley DB as an object store from perl via one of the many 'persist to hash' modules on CPAN) and the two tier nature of this way of hacking storage means that it is good and fast if you don't need to scale it or query it in as yet unthought of ways.
What WOULD be nice would be an upgrade path to relational data and replicated objects and transactions - but wait, that's what EJB's are supposed to do, isn't it?
If your OO design is right you don't need cross-object queries. You need cross table queries when you store objects in relational databases because you break your objects apart to store their attributes in the relational model, and have to put them back together again to get any useful query.
Posted by: Jimbo on October 25, 2003 1:28 AMThat's just not true in real world situations of any complexity. You can absolutely build OO models where most of the standard interactions required of your particular model make sense - but every object model is a tradeoff, based on the primary constraints of the problem. Sooner or later somebody is going to want reporting that is transversal to that design, and this is massively inefficient with this kind of simple storage.
Posted by: Dee on October 25, 2003 1:55 AM