yes, BUT - I find that by placing the internal linking value (non-editable) on an entry form GREATLY enhances the ability/simplicity of tracking down data issues.
ex (without viewable internal key): user: "... customer John Smith does not show the correct invoice(s) Dev/Sys admim: John Smith.. just a minute... hmm There are 43 John Smith's in the system, which one do you mean? user: you know JOHN SMITH! ......... [no need to continue :) ] ex: (with visible key): user: "... customer John Smith does not show the correct invoice(s) Dev/Sys admin: Can you please give me the number in the upper left hand corner, just below the screen title 'Customer Information'... user: 1234567 Dev/Sys admin: just a moment... Ok got it. Now what is the exact problem.... ......... [of course at this point getting the user to give useful information is next to impossible, but at least there is now a reference to the problem record/customer...] On Sun, 6 Aug 2017 13:08:14 -0600, npdennis via 4D_Tech wrote: > > On the other hand, you do model the data after business relations, > but the keys that tie that relation data need/should never be seen in > a well designed system. If a user readable key is needed by business, > then there should be another data piece that the user can read (like > an MRN, medical record number, or an abbreviation that is unique and > human readable) But these should never be used to link together data > in a structure in primary key foreign key relation. > --------------- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
