use-revolution Digest, Vol 66, Issue 47

Peter Alcibiades palcibiades-first at yahoo.co.uk
Sun Mar 29 03:26:29 EDT 2009


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.




More information about the use-livecode mailing list