use-revolution Digest, Vol 66, Issue 47

Jim Bufalini jim at visitrieve.com
Sun Mar 29 08:02:33 EDT 2009


Hi Peter,

First, I realized only after I sent my email that there were actually two
separate threads (the other called: Well I never!) on almost the identical
topic of someone trying to get their arms around understanding arrays within
arrays with respect to data and was just trying to be helpful. I responded
to the particular email that I chose because it had a real-life example,
instead of a Brazilian bus (which I found very funny). ;-) The rest of my
response to your email is in-line below.

> Jim, is not the problem with your method, what happens if one of the
> meeting
> places moves or goes out of business? You have then to go through every
> single record, find where that meeting place occurs, and change it.
> And the
> problem is that you have no single list of meeting places, so each
> person
> record is going to have to contain lots of details of each place, which
> leads to repetitive typing and errors etc.
>
> The problem is also going to occur:  what happens if the last person
> living
> next to a given meeting place dies.  Then your last record of that
> meeting
> place vanishes.  Then someone new moves in next door to it.  What do
> you do?
> How do you know from your data store that it even exists?

I agree using meeting places for the case in point cited was a poor example
of the use of the value of a nested arrays, for the very reasons you
mention. I apologize for any misunderstanding it may have created. 

I could have used a better example which, just like the person's current
address(s) which are unique and not likely to be repeated, there are other
examples that I could have used such as maybe prior addresses the person
lived and voted, spouse and offspring names, etc.? Not to be mailed to, but
for some data mining purposes?

Even the example of meeting places would not have been such a bad example
for a headhunter with worldwide clients and where the emphasis is not on the
location itself, but where each client "prefers" to meet at each of their
different locations around the world, and where the chances of this data
repeating (his mom owned donut shop in the States, or his grandma's house in
Canada) is highly unlikely. And, where once the client is deleted, the need
for these preference locations, just like his or her addresses, can be
deleted as well.

> Not knocking arrays, not knocking nested arrays either, but they are
> surely
> a real trap for the unwary if used as data stores, particularly for
> anyone
> who hasn't gone through understanding relational databases at a very
> basic
> level?  All these discussions do take me back to a very early class in
> front
> of an instructor and whiteboard.
> 
> "If you find yourself entering the same data more than once, you need a
> new
> table.  If you find yourself reaching for repeating fields, you need a
> new
> table.  In fact, you will need a new table more often than you ever
> thought
> possible before you took this class."   Been glad of that ever since.

I was not and am not advocating the use of multi-valued fields over related
tables. And, in fact, one does not preclude the other. Each has their place.
Again, I was simply trying to be illustrative of nested arrays and used a
poor example. 

As to your instructor, you could have been a wisea.., like I probably would
have been, ;-) and asked how many times had s/he created a separate table of
first names and last names because s/he realized the name Joe or Mary or
Smith was repeated? 

What about middle initials? There can only be 26 of them in the English
language? In fact, since there are only 26 chars, why not relate every
single char of every single word to a related table of 26 records, so as not
to "repeat" those chars over and over and over? ;-) 

In reality, the "rule" of never repeating "data" is often violated, when the
practicality of the very overhead of unique key and indexing and retrieval
exceeds the data itself and justifies, if not mandates, breaking the rule. 

Aloha from Hawaii,

Jim Bufalini


> --
> View this message in context: http://www.nabble.com/Re%3A-use-
> revolution-Digest%2C-Vol-66%2C-Issue-47-tp22759619p22765042.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
> 
> _______________________________________________
> 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




More information about the use-livecode mailing list