I understand what you're saying here. No further comments from me at this time.
-- Darren Duncan
Stevan Little wrote:
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
