Well I never!

[Jim Ault]

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