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. best regards Dalton On Thu, 11 Apr 2019 at 15:44, Richard Gaskin via use-livecode < use-livecode@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 > 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? > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode