Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] Object oriented model reprise

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Stephanie Gerson <sgerson@stanfordalumni.org>
  • To: <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] Object oriented model reprise
  • Date: Fri, 03 Sep 2004 17:40:10 -0700

whoa. Not sure if I completely understand what yalls are discussing
here, but it sounds like your mimicking my vision for the front-end (webs
of webs, relationships of relationships) with the backend. Beautiful.
Of course, rewinding all the way, we are ultimately mimicking the
ecological webs themselves...

Anyhows, I like what Lawrence wrote:
"Maybe this is a matter of orchestrating, coordinating massive amounts of
table lookups with one result of this process being that seemingly
unrelated information can be viewed by a user wishing to discover new and
possibly previously hidden relationships between things. Maybe you would
have tables of tables as with columns of attributes-as-other-tables."

Imagine! A database that not only allows you to learn about
relationships, but discover ones that you (and others) didn't even know
existed! Discovering the infinite interconnectedness between
everything...ok I am starting to sound like Dr. Brauner's but you dig it,
ya?

pace bambinos
*s

"Lawrence F. London, Jr." <lfl@intrex.net> wrote:

John Schinnerer wrote:
> Aloha,
>
>> Can you provide a layman's explanation of ORM with MySQL and what the
>> default/alternative would be?
>
>
>> What are the advantages offered by ORM as the object-oriented
approach?
>
>
> I'll leave these to Chad - he is more familiar with details of this
> stuff than I am.
>
>> Whhat does object-oriented mean in the ocntext of what we are doing
>> and how does it fiffer from non-OO methods?
>
>
> There's been a lot of posts on this already - check the archives for a
> reprise.

Thanks for posting this, John; it clears up a lot of confusion.

> IMO an object model for our project is much more appropriate than a
> relational-database model.
>
> Plant objects (stored in an object DB) would contain information about
> themselves and ways ('methods', meaning essentially bits of code) to
> share than information.

How do those bits of code (each possibly a microcosm of other bits of
code
as with plant taxonomical data) communicate with other bits of code
"attached" to
other objects, i.e. other plants, microfauna, microflora, mammals, birds,
reptile objects,
guild objects, pc systems objects (i.e. landforms involving weather
exposure, soil, water,
stone, wood, manade materials), water, soil, etc.

> This is essentially what real-world plants do - they 'know' about
> themselves and communicate with other entities in a variety of ways -
> colors and scents to attract pollinators and/or repel predators, root
> exudates to attract symbiotic micro-fauna or scare off predatory
> micro-fauna, and so on.

Just rambling - this is getting interesting.

This may be boring to the programmers but possibly useful to other
laymen.
Trying to think of an image that describes this real world system in
software terms.
I envision for the object model as a ball covered with stickum on a pole
in the wind
gathering information debris. Each piece of debris can send semaphore-
like signals to
other balls each with their own unique debris-array.

I'm trying to relate this to a touchgraph-like display and what happens
when negotiating
or navigating your way through one.

> In a relational-DB model, plants are abstracted as tables of
information
> 'about' plants, with columns identifying general
> attributes/characteristics of plants and rows containing specific
> information on particular plants.
> Instead of simply asking a plant object about itself in various ways,
> queries have to be constructed to de-abstract the abstractions created
> in making the tables, in order to extract the desired information
> 'about' the desired plant or plants.

Maybe this is a matter of orchestrating, coordinating massive amounts of
table lookups
with one result of this process being that seemingly unrelated
information can be
viewed by a user wishing to discover new and possibly previously hidden
relationships
between things. Maybe you would have tables of tables as with columns of
attributes-as-other-tables.

> Either approach can be made to do what we want.
> I think the relational databse approach will get really really nastily
> complex and hard to work with as we add complexity to both tables and
> queries.
>
> The object-oriented approach just seems way more appropriate - simpler,
> more like what we are trying to model.

> We are already a culture addicted to abstraction; I think plant objects
> in an OO database are less an abstraction than relational database
> tables full of bits of data about plants.

Can you explain this a little further?

Thanks,

LL
--
L.F.London
lfl@intrex.net
http://market-farming.com
http://www.ibiblio.org/ecolandtech
_______________________________________________
pcplantdb mailing list
pcplantdb@lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/pcplantdb




+++++++++++++++
Stephanie Gerson
sgerson@stanfordalumni.org
(c) 415.871.5683


____________________________________________________________________






Archive powered by MHonArc 2.6.24.

Top of Page