[Catalyst] KiokuDB, MongoDB and the NoSQL thing

[Darren Duncan]

Hakim Cassimally wrote:
> I think you may be right.  However I've spent barely 3 or 4 hours
> looking at how to port an existing application to Moose/KiokuDB and I
> think it may be an interesting thing to do.  Our current logic uses DB
> tables, with DBIx::Class, and some shims like ::DynamicSubclass.  It's
> powerful, flexible, fast, and very sophisticated for reporting.
> 
> But really, the more I think about it, our business objects would
> benefit from living in a treelike structure: a "module" might contain
> submodules with different business rules etc..  We can cope with the
> existing logic, but the roadmap of new features contains a few things
> that would seem to require massive re-engineering of our tables...
> 
> ... and though I'm sure all this business logic /can/ be represented
> in a relational DB, it might just require some deep thought.
> With Moose, you just create your objects and the rules that tie them
> together; then you plug it into KiokuDB and job done.
> And when you change your object structure, you don't need to think
> about how to model it, or how that will affect various other
> relationships and queries.  I added the bulk of one of the
> "complicated" features I was worrying about representing with DBIC in
> around 30 minutes.

At any time in the near future, I would be happy if you, or anyone, wanted to 
share with me (most likely privately, and I can sign NDAs if needed) their 
particular business rules, ideally in the form of a requirements document that 
just says what you actually want to express in human terms, rather than saying 
it in the form of SQL or Perl classes because it is very likely that those would 
contain significant circumlocutions (and hence would add details that are 
actually unimportant but I can't tell), and then I will try to formulate Muldis 
D renditions of your business rules, and see if Muldis D can represent them more 
faithfully or with less circumlocution than other methods, and if not then this 
may point out things to improve in Muldis D's design; its fine to include the 
SQL or Perl also as illustration, but separate requirements are important for 
best interpretation of those; thank you. -- Darren Duncan