Permaculture Database

["Lawrence F. London, Jr." <lfl@intrex.net>]

-------- Original Message --------
Subject: Re: [permaculture] [Permaculture International]  database, wiki,     
  blogs, forums, etc
Date: Mon, 18 Dec 2006 09:04:51 -0800 (PST)
From: Sean Maley <semaley@yahoo.com>
Reply-To: permaculture <permaculture@lists.ibiblio.org>

This discussion might want to move over to a techie area,
as this can't be pleasant for the non-techie subscribers.  However, I do want
the community to understand costs involved to maintain a presence on the
internet.  Many of us are paying out of pocket, or must be creative regarding
TOS (terms of service).  Together, we can reduce these burdens by supporting 
any
number of permaculture charities, who could then sponsor such endeavors.

Bouncing apache, [whatever] db, perl CPAN reconfigs, etc are
all good reasons to have root/sudu.  This keeps me from quoting anything other
than co-lo services when discussing the coop.  You can get a free host, if you
don't mind a few advertisements of your unchoice.  It would be nice and cheap 
to
go for the shared servers, which usually include root access on a virtual 
server
($20/mo to $60/mo).  Preferably, we co-locate a system of our supply ($45/mo),
or lease a co-located system ($55/mo to $300+/mo).  Since storing free PCs is
more of a problem than finding them on NYC streets, I really would like to see
several ecovillages with favorable bandwidth and TOS using solar/wind power; 
I'd
be happy to network along computer equipment to you.  I could easily set up
round robin scripts to create "high availability" across multiple global
locations.  A comprehensive data-center at an ecovillage would cost thousands
per month, just for bandwidth.

DB development for a simple wiki, blog, or
PFAF wouldn't chew up much IO or CPU, so isn't much of a threat.  The problem
comes when we wish to move beyond storing data and recalling easily defined
records (OLTP - OnLine Transaction Processing).  Analytical DB development 
(OLAP
- OnLine Analytical Processing) should be isolated, even for QA iterations.
Although mixing OLTP and OLAP designs seems common, it can be an exercise in
frustration (picture frozen programs when the OLAP analysis happens, which can
happen at any moment, per the definition of "OnLine").  If you want new
information from analysis, not the data you already know, the requirements
change considerably.

An alternative would be to simply enter guilds like
you enter a recipe.  Users would then look through articles via a Google like 
search tool.  Perhaps
latitude/longitude parameters could hone the guild examples, but there would 
be
no analysis like searching through crop yields to find the best guild using 
the
same search parameters.  In OLAP terms, the storage keys (species, guild, 
time,
location, etc) would be called dimensions.  The values stored across these
dimensions are called measures.  We have yet to define measures and dimensions
to do analysis.  "Guilds including a species" searching means OLTP.  "Guilds
exceeding a given average yield in tons per hectare" would be OLAP.

An
OLAP tool would be very useful after a number of years of data collection.  
For
the OLTP solution, stick to PFAF and Google.  For the USA, the PLANTS database
also provides great information (advanced search useful to identify say native
N-fixers found in your zipcode).  Sorry Rich, but even the 'eden' database is
poorly structured (further normalization would be tedious, inconsistencies 
make
potential SQL results unpredictable; the uses given per species are an example of inconsistency, species also hard to 
line up to USDA and ITIS data; not to mention endless cultivars yet to be included with variations from the information 
given in eden).


-Sean.