On 5 Jun 2012, at 05:59, Barbara Passman wrote: > Am simply asking is it better to make iterations of tables so that I do not > burden one set of tables with all the relationships in case one criterion > (match field ) does not match.
It does sound simple, but the answer to 'which is better' likely depends on the purpose. Your question hints to me that you are maybe trying to make what we might call a 'fuzzy' match between people in two tables. That is, you are wanting to match possibly incomplete data and, perhaps, will use the results to offer hints to a user of the database as to what the matches are. Obviously, one way to do this is to create (in your example) three separate relationships – telephone number, last name, first name. You could then display each relationship in a portal. But making sense of the results may not be very straightforward. Say you are sitting on your record in one of the tables. The First Name portal is going to display all the Barbaras in your second table (which would include you but also my sister). The Last Name portal is going to display all the Passmans – you, all your Passman relatives, as well as any unrelated Passmans. The Home Telephone portal should, if the data is correct, display only one record. It might be yours, but if you have recently changed phone numbers for some reason it could be someone else entirely. Does this data make any sense? I'm not sure what the 'better' solution is. I might look into whether multi-line keys could help give a better set of hints. With respect to the question at the end of your post, whereas a multi-predicate relationship as you describe (using three separate match fields in one relationship) will give you matches where First Name AND Last Name AND Home Telephone match, a multi-line key will give you a match for First Name OR Last Name OR Home Telephone (that is, if ANY of the fields match). Steve
