On May 29, 2010, at 10:07 PM, Daniel Pittman wrote:
Stevan Little <stevan.lit...@iinteractive.com> writes:
On May 29, 2010, at 10:37 AM, Shawn H Corey wrote:
Is the a standard methodology for persistent objects in Moose
using SQL?
I'm writing a small web spider and I want my sites to be persistent
objects.
Personally I would recommend using KiokuDB. This is the most
straightforward
way to persist Moose object as it is specifically made to do
*exactly*
that. KiokuDB seems magical and crazy (object graph persistence
engine, wtf?)
but it is really pretty straightforward and we have used it
extensively at
$work on all our major client applications with great success.
Can you recommend which storage back-ends are most likely to "not
suck" when
someone uses this in a technology trial?
I keep eyeing off KiokiDB and some of the other JSON-based storage
engines,
for a couple of projects we have at work where they seem a much
better fit.
Using a back-end that doesn't suck without having to learn which one
that is
myself seems useful, since I don't want to unfairly punish the tool
for my own
mistake. :)
Personally I like the DBI backend, and we have used it several times
with great success. Here are several reasons why I like it:
1) I can use all the existing tools for the RDBMS
For instance, if I use MySQL then I get the mysql shell, mysqldump,
etc. This might seem trivial, but other backends like BerkeleyDB
doesn't have these things so the data feels much more opaque. Some of
the other backends like CouchDB, Redis and MongoDB have similar tools,
but IMO they are not as battle tested as MySQL.
2) I can easily put my DB on another machine
The standard breakdown of the web server on one machine and DB on
another is trivial to accomplish using the DBI backend, the same is
not true of the BerkeleyDB backend (IIRC there is a way to do it, but
its a PITA). The CouchDB, Redis and MongoDB backends (I assume) do
also offer this too, but you are more likely to have a MySQL DB setup
then you are one of those three.
3) It can fit easily into existing systems
This is sort of the result of the combination of #1 and #2. Chances
are you already have a RDBMS setup somewhere along with an existing
backup strategy, etc. etc. All you need to do is add 2 more tables and
you have KiokuDB set up. This means it is also very easy to have
hybrid systems with both KiokuDB and a more traditional RDBMS sitting
side by side. In fact, the first really large KiokuDB project we did
at work is exactly that and has been successfully running in
production for well over a year.
4) The data is pretty "transparent"
The layout of the DBI tables is pretty clear and getting at that data
is pretty easy, if I ever were to want to move away from KiokuDB I
would still be easily able to extract the data, even without KiokuDB
itself.
Bonus points if it is a storage engine that we can work with outside
the
Perl/Moose space too.
See also reason #4. It would be entirely possible to extract the
information in the KiokuDB DBI storage backend with the available
tools in just about any language out there. Basically you just need
database access and a JSON parser.
- Stevan
