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
