dalton.calford at gmail.com
Thu Apr 11 15:47:22 EDT 2019
I was about to explain using screen shots, flow diagrams etc., but, then I
thought this may not be the best place to be discussing this.
If you think this is as good a list as any, I can proceed, but, I will have
to do so later this evening as I am about to start a MOP.
On Thu, 11 Apr 2019 at 15:44, Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:
> 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
> > 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
> > 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
> > 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
> > 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
> > number][street name] while the second is [plot number][rural road
> > number][municipality]. So two addresses, in the same table, with
> > 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
> > manage.
> > For example, lets say, you have 100 addresses, each address is in one
> > 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?
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode