On May 29, 2010, at 11:20 PM, Darren Duncan wrote:
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?
It does pretty much what you are proposing, the serialization has to
happen because we need a storage format, but there is not ORM or
impedance mismatch with Kioku (It does use DBIx::Class internally, but
not as an ORM, only as a clean efficient way to interact with the
storage engine).
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.
KiokuDB mostly uses JSON and JSPON as the storage format, which is not
Perl specific. The serialization format we store in is dependent on
the Moose class definition, so in that way it is not terribly portable.
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.
And then you get the impedance mismatch. You are ignoring inheritance,
which is not really possible in a relational model.
Remember, objects are graphs not sets of tuples.
- Stevan
