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 > [email protected] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
