Permaculture Information Web

[Chad Knepp <pyg AT galatea.org>]

Marco Stahl writes:
 > 
 > > Von: Chad Knepp <pyg AT galatea.org>
 > >  > Something like 
 > >  > 
 > >  > entity     |  output
 > >  > ----------------------
 > >  > Leguminosae  nitrogen
 > >  > animal       shit
 > >  > 
 > >  > would simplefy the adding of new plants(and other entitys), creating
 > >  > patterns for groups of plants(and other entitys), adding/changing 
 > >  > properties/patterns for whole plant(entity)groups.
 > > 
 > > My proposal attempts to solve this with the use of sets.  Example:
 > > 
 > > entity              |  output
 > > --------------------------------------
 > > set(all Leguminosae)   nitrogen fixing
 > 
 > 
 > Maybe I'm wrong, but I thought in MySQL:
 > "A SET datatype can hold any number of strings from a PREDEFINED list of
 > strings specified during table creation."
 > 
 > That doesn't sounds like "easy updating" or adding user contributed
 > rules,plants :-)

Well you're not wrong about MySQL, but I wasn't actually thinking of a
SET datatype.  By set I meant that from an end user perspective one
could select all plants from the family leguminosae and not have to
enter the relationship again each time for each plant.  The client and
server actually sort out the important details and for each plant with
said relationship there is a row in the table.  

In my implementation, the hard part is relating sets to other sets
particularly when it is set(all plants); the largest relationship.
This would probably need some sort of notation that would violate the
laws of full normalization.  Otherwise a simple seeming relationship
of set(all plants) has X relationship with set(all plants) generates
num(all plants)^2 rows... currently that would be about 54 million
rows.  Using some sort of notation in the Other Entities column would
reduce the largest possible relationship to a little over 7k
rows... very feasible.

I'm not that attached to the implementation I'm suggesting, but I need
to understand and be convinced that another implementation is going to
be better suited.

 > > Ok, I'm still not sure about why this is important but I see it at
 > > best as being 5-6 levels of hierarchy which will not affect
 > > performance.  Something like: 
 > > 
 > >   entity | parent
 > >   ---------------
 > >   creature NULL
 > >   animal   creature
 > >   plant    creature
 > >   leguminosae plant
 > >   soya     leguminosae
 > >   max         soya
 > >   'Chiffumy' max
 > > 
 > > The real problem with this is that entity will not be unique which
 > > requires you to know a little more about the entity than just the top
 > > level.
 > 
 > Sorry i don't understand, "not unique"???
 > In my example tables I use the names just because of readability.
 > Every entity should have a unique numeric ID ('Chiffumy'=143423425).

Ha! Here we reverse our misunderstanding.  Yes a unique id would solve
my concern.

As I think about this particular table (abstracted from the
implementation of relationships) I think you are on to something
important that I hadn't considered before.  When I go about the
process of designing/modifying guilds I often look to make changes
first at the level of cultivar, followed by species, genus, and then
family.  Not finding suitable representatives on a family level I look
elsewhere.  Anyway, I can see the usefulness of this information in
generalizing about potential guild members.  

 > Saludos, Marco

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'