Permaculture Information Web

[Sean Maley <semaley AT yahoo.com>]

This may be more appropriate for the pcplantdb
listserv.  Perhaps it should be carried over.

Your thoughts are just as valid as mine below. 
Hopefully I am adding to the discussion. 
Unfortunately, I don't have enough time to think this
through, so feel free to sling mud if I'm missing
anything.

--- Marco Stahl <marco.stahl AT gmx.net> wrote:

> Hi all!
> 
> Maybe its possible to express Relationships as
> INPUTS/OUTPUTS of an entity
> (plant, animal, human, machine,...).
> 
> An Entity could also be a category.
> 
> Example:
> 
> entity | parent
> ---------------
> creature NULL
> animal   creature
> plant    creature
> bean     plant
> hemp     plant

Where searches represent the fundamental activity with
the dataset, OLAP, we may consider keeping the schema
denormalized; creature_type: A, M, V (animal, mineral,
vegetable) rather than get into hierarchical data
sets.

--------------------
|creature_dimension|
--------------------
|creature_key      | : hemp, bean, etc
|creature_type_key | : A, M, V
|ground_depth      |
|height            |
|....              |
--------------------

> 
> 
> entity  | OUTPUT
> ---------------
> bean   nitrogen
> hemp      climb help
> hemp      seed
> hemp      fibre
> 
> 
> entity  | INPUTS
> ---------------
> bean   climb help
> hemp      nitrogen

Most outputs have a corresponding output.  So it isn't
enough to say your input/output is some quantity, but
rather some input yields some output.  Additionally,
most relationships are complex, so there are numerous
inputs that yield numerous outputs.

-------------------
|product_dimension|
-------------------
|product_key      | 
|product_desc     | : nitrogen, seed, fiber,
|                 | : climb help, etc
|....             |
-------------------

-------------------
|relationship_fact|
-------------------
|creature_key     |  : bean, hemp, etc
|in_product_key   |  : N, seed, fiber, etc
|min_in_amount    |  : +/- qty, g, l, m, etc
|max_in_amount    |  : +/- qty, g, l, m, etc
|out_product_key  |  : N, seed, fiber, etc
|min_out_amount   |  : +/- qty, g, l, m, etc
|max_out_amount   |  : +/- qty, g, l, m, etc
|production_time  |  : days
|....             |
-------------------

The sign accounts for when an input causes a decay for
a given output; over watering, nutrient burning, etc.

> 
> 
> We could also include the amount of the produced or
> needed product and
> reduce OUTPUT and INPUT to INPUT/OUTPUT. 
> 
> entity    | (INPUT)/OUTPUT    | amount
> -------------------------------------
> bean   nitrogen     100
> bean      climbhelp         -100  
> hemp   nitrogen          -100
> hemp      climb help         50
> hemp      seed       50
> hemp      fibre       50
> 
> 
> If Hemp is normaly a average "climb help" but a good
> one for beans, we could
> express that in this way:
> 
> entity    | (INPUT)/OUTPUT    | amount
> -------------------------------------
> bean   nitrogen     100
> bean      climbhelp         -100  
> hemp   nitrogen          -100
> hemp      climb help         50
> hemp      climb help bean    100
> hemp      seed       50
> hemp      fibre       50
> 
> or alternativ:
> 
> entity    | (INPUT)/OUTPUT    | amount |
> targetentity
> --------------------------------------------------
> bean   nitrogen     100         
> bean      climbhelp         -100  
> hemp   nitrogen          -100
> hemp      climb help         50
> hemp      climb help         100        bean
> hemp      seed       50
> hemp      fibre       50
> 
> 
> Advantage of this approach:
> ---------------------------
> 
> * No need for writing 10000000 relationshipentries
> just for the fact, that 100 plants produce something
> that all other plants need (can even
> reduced/automated more with help of categories)

  10 00 00 00

This is what hierarchies do to IO and why 10,000,000
records can be more effective.  First, an index can
get you into that 10,000,000 with reasonable
efficiency.  However, an index may not be effective on
100 records, so all your searches become 100 with an
exponent of your hierarchy depth with full table
scans, rather than an index scan.  I'm not saying it
isn't the answer, but one should be very wary in terms
of using it as an architecture; real record numbers
need to be specified prior to making this decision.

If you ended up with 1000 records instead of the
anticipated 100, you get:

  10 000 000

Three hierarchies deep become significant relative to
the work being demanded verses having room for four
levels of hierarchy.  Although this over simplifies
the discussion, a healthy respect for hierarchical
queries is required nevertheless.

> * you can easely integrate other entities than
plants
> * you can easely express uses as products (and
inputs
> of the entity human)
> * you could even express stuff like "a plant needs
> wet soil, high temperature"
> * maybe: (semi)automatic
> guild/permaculture-design-generation
> 
> 
> I hope you like my ideas,
> 
> Saludos, Marco
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com