Well I never!

[Thomas McGrath III]

Jim, Absolutely love this. Thanks.....


Tom McGrath III
Lazy River Software
3mcgrath at comcast.net

iTunes Library Suite - libITS
Information and download can be found on this page:
http://www.lazyriversoftware.com/RevOne.html

On Mar 28, 2009, at 12:09 PM, Jim Ault wrote:

>
>
> On Mar 28, 2009, at 7:15 AM, Thomas McGrath III wrote:
>> OK, Jim so now we all know that you can get really cheap bottles of  
>> asprin.
>>
>> Great concept to explain multi-dimensional array's. And this works  
>> great for individual 'different' types of objects. I would like to  
>> see an explanation of similar objects:
>> Let's say you have a collection of baseball cards. You may have a  
>> lot of duplicates and you may have missing cards that you want to  
>> list. They all share similar attributes like price, stats.
>>
>>
>> collectibles[baseballcards] ....
>>
>
> The short answer is that you would program the location rules for  
> all the data and let your loops and handlers to the detail work.   
> One example is "How many all star first basemen do I have/need/want?"
>
> A longer answer to your question: the single concept would be  
> 'fingerprint', or in database terminology, 'ID', such as  primary ID  
> that is always unique and automatically assigned.  Without a unique  
> ID in a table, a database cannot build linking tables that do the  
> chores of lookups and record sets.
>
> Since the Rev arrays do this by the rule that keys must be unique  
> and less than 255 characters (the Rev limit might now be different  
> than this), you have a wide range of ID choices.  The actual system  
> you devise is up to you and can be different on each level of keys.
>
> Think of an array as a table on an Excel spreadsheet, with the rule  
> that column 1 can only contain unique values (this is like a Rev  
> key).  At this point, column 2 on row 11 could contain any string
>
> The sheet name would be 'collection', each row would be the same as  
> the smallest level you would want to track in your system, or schema.
>
> Example:
> [Rocky Colivito-Cleveland-RookieYear-MintCondition-$1465value - 
> $0.10purchasePriceIncludingBubbleGum] "in green shoe box"
> ----a very long key, but unique
> collection[person][player][team][year][at bat][rbi][position]
> collection[person][coach]
> collection[team]
> collection[special][world series][2001]
> ----- oops, this won't work too well since there are many  
> collections with 66 Rocky Colivito's
> Back to the unique ID number or string that would be assigned to any  
> entry in the table as column 1 of the spreadsheet.
>
> The 'granularity' of the array keys (tables) has to be determined by  
> the programmer since this is the basis for any data storage and  
> retrieval.  You could assign a bar code to every card, if you only  
> collected cards, but then you would have to consider commemorative  
> packs, and other oddities, like Barry Bonds before and after  
> confession, McGwire before and after confession, etc.  You know, the  
> double-triple-fourple asterisk ratings of the future.  You would  
> need to keep track of the number of years of enhancers, as well as  
> the year started, and when he says he quit.
>
> Another wrinkle would be the trading to different teams in the off- 
> season and mid-season.
>
> One of the real questions any database programmer would need to ask  
> is "what do I want to do with the data?"  If it is very fast  
> reporting in a simple setup so you don't have to do a lot of  
> programming, or very fast-yet easy to maintain and expand and no  
> need to print any reports.
>
> The bottom line is the schema and the intended use of the database.   
> Most databases handle the complexities of collections by using  
> (unique keys or IDs) plus relationships plus indexes.  An index is a  
> table that lists ID's so that groups are faster to report, but  
> require creation and maintenance by the database programming logic.
>
> In Rev, I would build the multidimensional arrays and apply the  
> rules on the back-end, using filter commands.
>
> Example:
> if collection["person"] is empty --nobody in there yet
>
> put the keys of collection["person"] into tempList
> filter tempList with "John*" --exact match required
> if tempList is empty then -- nobody in there named John-something
>
> With an associative array, like Rev's, you probably will run the  
> danger of duplicate and scattered data.  Legal and accurate, but it  
> soon gets unwieldy and you would store all of your shoeboxes in the  
> bedroom in the closet next to a very big bottle of cheap asprin.
>
> The short answer is that you would program the location rules for  
> all the data and let your loops and handlers to the detail work.   
> One example is "How many all star first basemen do I have/need/ 
> want?"  "Do I want to store the scanned image or just the path and  
> filename in the database?"
>
> If your goal is to display the data like they do on CSI Miami on a  
> heads-up holographic voice activated display that takes exceedingly  
> private information and shows it to anyone walking by, then you have  
> to go with a fake database.  Much more fun and great at parties.  Of  
> course that would add another key ["soundtrack"]
>
> I hope this gives you a little insight into my limited knowledge of  
> databases.  The only database I have done that is really good and  
> that I am proud of is my office.  Ever-changing and carefully  
> disorganized.
>
> Jim Ault
> Las Vegas
>
>
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution