Panel/Form Widget

[Richard Gaskin]

This is a very interesting description of a graph database application.

But how does it relate to having a stack viewable within another stack?

-- 
  Richard Gaskin
  Fourth World Systems


Dalton Calford wrote:

> ok,
> 
> In order to explain what I need the utility for, is as a front end to a
> highly normalized warehouse Temporal Graph database.
> That probably means nothing to you, but, lets assume it does for the time
> being.
> 
> For a simple example, lets say we are dealing with addresses, 2.6 billion
> addresses, along with geo location.
> The database does not contain nulls, data tuple width is variable based
> upon a recursive multi-parent relationship.
> Language/Locale information is part of the data structure
> The client connects to a local embedded database which only is used for
> work que's and caching and it in turn will connect to the middle tiers for
> data synchronization/load balancing
> Authentication is a round robin authkey token passed between the various
> layers over an encrypted database to database channel.
> 
> (no, this is not star trek technobabble, it is actually a 10000' summary of
> a specification)
> 
> For discussions sake, lets agree upon some terms.
> 
> *Viewers* is not natural to me as I never heard the term used before this
> discussion.   Lets use a different term
> 
> *DataPanel :- *This is the ultimate goal.
> 
> 
> Ok, in order to explain what is going on, lets begin with a description of
> a data warehouse problem.
> 
> A simple address.
> 
> An address has multiple elements, almost all of them defined identically -
> a text string.   Depending upon your location on the planet, the details
> are very different.   You could have street numbers or a building number
> within a block.   You can have rural or municipal addresses etc.   Not all
> address fields are needed for every address, and you do not want a single
> null (undefined data) in the database.
> So, in order to handle this, each address has a unique id, this is the
> master link.   That master link is also linked to a definition of fields
> that comprise this particular address.    So, the first address is [street
> number][street name] while the second is [plot number][rural road
> number][municipality].    So two addresses, in the same table, with totally
> different columns.   You can add columns to the addresses on the fly, you
> can even self populate the columns (surface them) based upon postal code.
> Now, this is a full discussion on its own, but, it makes data very easy to
> manage.
> For example, lets say, you have 100 addresses, each address is in one city,
> that city is in a state and that state is in a country.
> Each one of those addresses would have a pointer to the city, which has a
> pointer to the state, which has a pointer to the country.
> So, you only ever have the country entered once in the database (with a
> list of how it is used in various languages), same with state and city.
>  This cuts the total size of the database enormously.
> 
> In order to handle a situation like this, you need a series of embedded
> datapanels.
> 
> hmmm, I am thinking this may be very boring for the majority of people on
> this list, perhaps there is a better list than 'using livecode' for this
> discussion?