Skip to Content.
Sympa Menu

piw - Re: PIW Relationships Modelling

piw AT lists.ibiblio.org

Subject: Permaculture Information Web

List archive

Chronological Thread  
  • From: Sean Maley <semaley AT yahoo.com>
  • To: Permaculture Information Web <piw AT lists.ibiblio.org>, Permaculture Plant Database <pcplantdb AT lists.ibiblio.org>
  • Subject: Re: PIW Relationships Modelling
  • Date: Fri, 15 Jul 2005 08:38:51 -0700 (PDT)

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




Archive powered by MHonArc 2.6.24.

Top of Page