Stevan Little wrote:
The only drawback to KiokuDB is that since it stores the object graph
rather then trying to map the object to a set of SQL tables, your data
is not stored in a relational/tabular way and so not (easily) queryable
using those tools. Of course this can also be seen as a benefit as well
(I know I see it that way), since you are not constrained in your OO
design by the limitations and infamous impedance mismatch that comes
with ORMs. And of course KiokuDB does have it's own set of tools as
well, just look in KiokuDB::Cmd (this has load, dump (for the whole DB
or just one entry), edit, fcsk and a garbage collector) and there is
KiokuDB::Navigator which provides a web based view of your KiokuDB.
Two points I can make on this ...
1. I don't have KiokuDB's documentation in my head at the moment, so forgive me
if this is in there but, ...
Have you ever considered making KiokuDB able to directly store objects without
serialization as relational database records rather than going through some
other Perl ORM layer, and so hence you avoid the impedance mismatch from ORMs
layered in between?
2. Besides the ability to introspect or perform powerful searches on your
objects using SQL/etc, I see another big advantage of using database storage
without serialization as portability. You can have applications written in
different programming languages sharing the same database and the same objects,
because they don't contain Perl-specific data formats.
A relational database can map to an object structure of any language fairly
easily. Add attributes/columns for mutually heterogeneous data, like when you
would add object attributes, and add tuples/rows for mutually homogeneous data,
like when you would use arrays or sets.
-- Darren Duncan
