On May 30, 2010, at 6:07 PM, Darren Duncan wrote:
Stevan Little wrote:
It also does not deal well with polymorphism since the ID (the
object's identity) is essentially fixed to a table (usually mapped
to a class).
The ID (object identity) that I had in mind would be unique across
all objects in the system regardless of their class, and wouldn't be
fixed to a single table.
Sorry, yes I was more referring to the other inheritance approaches
used by ORMs. If you have a Person class and an Employee class where
the Employee extends the Person. The most common way I have seen ORMs
handle this is to have a Person table and an Employee table neither of
which have any real relationship to one another. The result is that
you basically lose polymorphism because there is no easy way to treat
an Employee as a Person since the Employee's ID is fixed to the
Employee table and not the Person table.
Of course there are other approaches, but they essentially all end in
tears, so there is no reason to rehash them.
Let me just be clear, a relational database is a powerful tool and
when you have tabular data it is far and away the best tool for the
job. When you have object data, in particular object data that doesn't
easily "flatten" into tabular data, then a relational database is the
wrong tool for the job.
KiokuDB is meant for the later and should never be used to implement
the former.
The best example I can give is one of our survey reporting applications.
The survey and demographic data is inherently tabular and we perform
many aggregate queries on it, therefore we store it in a relational DB
and would never do otherwise. However, the system configuration
information and user account information is very much not tabular and
most of the time we only ever query a single entity by ID, therefore
we store this data into KiokuDB (using the DBI backend so that both
datasets are actually in a single DB schema). The result is that we
could simply design our Moose classes in a way that makes sense in
Moose-land and need not worry about how it would map down to a
relational schema. The lack of need for compromise and tradeoffs makes
the entire design process much faster and more enjoyable.
We were even able to have implicit relations between our Kioku objects
and our relational data, simply by sharing IDs in the way you would in
a purely relational model. Sure we lost out on any RDBMS constraint
checking, but in our particular case it wasn't a big loss.
- Stevan
