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? 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. -- 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
