Stevan Little wrote:
I think you misunderstand, KiokuDB is *not* just a JSON serialization
service, it breaks up the object graph on a per-instance basis and
stores each instance separately. It uses JSPON as a way to handle
references from one object to another.
<snip>
I think perhaps you need to take a much closer look at KiokuDB because I
suspect you have not done so and so are pointing out issues that you
perceive it to have, but in fact, it does not.
You are right, I should look at KiokuDB more closely so I know better what I
speak of concerning it. I'll do that when I have the opportunity.
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.
But this is a well worn topic and there is no need to beat this dead
horse one more time.
Fair enough. I have no need to push any particular design.
One should think about the database schema like they think about their
code. It is just as reasonable to change the schema as it is to
change what classes you have or what attributes they have. The schema
*is* code, and the data it holds is like objects of classes. No more,
and no less.
That is a very DB centric viewpoint and I disagree with you completely.
Changing a schema during development is one thing, changing it after
deployment, after you have started to collect data, etc. is another
thing entirely and very much a non-trivial task.
Changing one's application code after deployment is also something one has to be
cautious about, and I consider changing some parts of your application analogous
to database schema changes, such as changing the classes in your application
that represent your primary data. You wouldn't change an in-production
application lightly either. Or to be more accurate, changing the APIs or
behaviour of application modules that may be used by multiple applications, is
probably a better analogy to a database schema change.
But then, how well you can do this depends a lot on your project design. For
example, a relational database that utilizes VIEWs to present different APIs to
the same data, or that uses database stored procedures to mediate access from
applications to the database data, rather than applications seeing the tables
directly, also makes them much easier to change.
When I say that a database schema is code, it is probably more accurate to say
that this code is like a shared library rather than an application, and so
changes to it risk affecting multiple applications. But not too much more so
than a shared library in Perl. That is how I see it.
-- Darren Duncan
