Permaculture Database

[Paul d'Aoust <paul@heliosville.com>]

On Sat, 2007-31-03 at 00:54 +1000, jedd wrote:
> > Having thought this far, we can begin to sketch out a data model and draw
> > an E-R diagram for the Guild database.
> 
>  My requirements extend far beyond either a database of facts about
>  plants, and/or a database of facts about relationships between those
>  plants.
> 
>  Can some other people pipe up on this subject please -- what are
>  the ultimate expectations of this (the larger of the two) systems?

Myself, I have fairly modest desires: a database that

     1. lists information on plants, animals, and other entities
     2. connects those entities with relationships
     3. allows people to store information on established relationships
        (in other words, guilds)
     4. allows people to find further information on those entities,
        through wikis, links to other resources, and so forth.

> > This structure might have to be expanded to account for climatic and
> > regional variations.  This could be done by adding an additional layer of
> > abstraction underneath that proposed above.  You would use the structure
> > described above to track the essential elements of a guild in their most
> > generic form.  Then you would add tables with a similar relational
> > structure for tracking guilds in more specific areas.
> 
>  I'm not sure I understand how you anticipate this would work.
> 
>  Would there be multiple rows for 'peach' depending on where I
>  was growing my peach and you were growing yours?  How does
>  your scheme handle such duplicates in this case?

I think that the basic information presented should be an amalgamation
of everyone's weightings and ratings. If someone says that something
works in zone 6, but someone else comes along and says they've
successfully kept it alive through a zone 5 winter, then the basic info
page should say zone 5 - 6 or zone 5.5 or something.

If we want to include site-specific information, then there'd be
something near the bottom that says, 'Read about the experience of
people near you', which would take you to a page that is generated from
a junction of 'object', 'attribute', and 'site', or something else
really complicated :-)

To be honest, I have no idea how to resolve the dimensions introduced by
adding site-specific info. It may make things too complicated; this is
something we should figure out.

>  Removing specificity of data is obviously a one way street, and
>  there seems to be little benefit in doing so given my gut feel on the
>  size of data I'm thinking about and the power of modern tech.  Worst
>  case you could of course separate out your olap data to a different
>  system if performance was ever an issue .. but I see that as a very
>  long way down the track.

Indeed. I don't think we need to look at OLAP concepts quite just yet --
if I understand them correctly, they're used for huge, mostly
chronologically oriented data sets. I don't know that there'd ever be
enough manpower to create/edit a PCDB that big :-)

> > In any event, I think it's best not to design unnecessary complexity into
> > the database.
> 
>  Herein may lay the quintessential difference between our views.
> 
>  I think it's :
>  a) very important to design flexibility from the outset, as it's nearly
>      impossible to increase the flexibility of a system once it's in
>      production, and
>  b) pretty much impossible to determine what level of complexity is
>      necessary at the design stage, particularly with systems that are
>      not well spec'd (screen mock ups would go a long way here) and
>      whose functionality requirements are almost definitely going to
>      grow over time.

I have a question: what is everybody's interpretation of the concepts of
simplicity, flexibility, and complexity in this context?

I vote for 'robustness and flexibility', which is something the UNIX
programming world has always loved. If we do a good job of creating very
generic objects that talk to each other in very straightforward ways,
we'll be able to connect them together in very complex ways. If we
create complex, detailed objects, we may get frustrated in the future
when we realise that we should have rolled off

object
---------
objectID
objectName
height
yield
soilNeeds
moistureNeeds
energyNeeds
nitrogenNeeds

into

object          objectToAttribute       attribute
---------       -------------------     ----------
objectID <--\   objectToAttributeID  -> attributeID
objectName   -< objectID            /   attributeName
                attributeID >------

or something of that sort, and then fill the 'attribute' table with
'nitrogen' or 'full sun' or what have you. (I can see huge problems with
my example, like the fact that there's no way to specify the exact
amount of water something needs, but I'm just using it as an example of
simplicity and abstraction being able to create very complex and
flexible interactions.)

Paul d'Aoust