On Jun 2, 2010, at 10:52 AM, Shawn H Corey wrote:
I want to thank all those who responded. Your comments have given
me a view of the state of the art as it currently exists.
And from what I gather, it sucks.
Wow, that is a strong statement that doesn't really match up with what
I know. Between DBIx::Class, Fey::ORM and KiokuDB you have your choice
of 3 top-shelf solutions, which is pretty un-sucky if you ask me.
There is a lot of software that stores objects in a RBD and they do
a good job. The problem is that while there the models for objects
are well-formed, normalized relationships, there are no relations
about the data in the objects. Concepts like primary key and foreign
key are not part of Moose and without them, building a reliable RBD
is very difficult.
Primary key and foreign key are meaningless to Moose because that is
not how objects connect to one another, that is how you imply
relationships in a RDB. I think perhaps you're too stuck in RDB
thinking, keys are most certainly not a requirement for a decent
persistence solution. This is also less an issue of Moose and more an
issue of the impedance mismatch between OO and RDB, which at this
point seems like a unsolvable problem.
Not that I need them for the project I had in mind; it's so small
that virtually any technique could be used. I was hoping I could
learn something I could scale to larger projects.
KiokuDB actually scales really well, what ever gave you the idea that
it wouldn't? DBIx::Class and Fey::ORM scale equally as well if not
better since they can take more advantage of the native RDBMS
strengths in query optimization. Also, scaling large enough that any
of these tools would start to show strain is a problem you (or anyone
really) is unlikely to have. However, if you are lucky enough to have
a scaling issue often times some creative caching will get you the
next few miles. And if that isn't good enough and if you were to use
KiokuDB you could perhaps use the MongoDB backend to take advantage of
the high availability scaling and sharding features it has. Although I
have spoken to a MongoDB engineer recently and even their largest
clients (NY Times, SourceForge, github, http://www.mongodb.org/display/DOCS/Production+Deployments)
have not actually needed to use many of these features or use them
very heavily.
Seriously, I suspect that any of these tools will handle just about
anything you can throw at it and keep up just fine (assuming you have
designed things correctly).
I was hoping for some special tools that would allow me to mark my
objects and their attributes so that the RDB was explicit. Guess
I'll have to roll my own. ;)
Okay, so KiokuDB doesn't do explicit "magic" style persistence, but
that really is not the correct division of responsibility. The object
instance itself should not know from where is came or where it needs
to store itself back into, that would be more appropriate as part of
the class, but even that is iffy. And honestly if you are thinking of
scaling really large then you do not want "automagic" persistence, you
want fine grained control over how and when you persist your objects
so that you can optimize things in batches, etc.
- Stevan
