Mike A. Schwab writes: <begin extract> . . . Just use the same program in case you need to change a legitimate customer number for some reason. I. E. two customers who keep using the same number when they call in. <end extract>
In fact use that program twice. The only safe thing to do in these circumstances is to give both of these customers new numbers. Duplicate customer numbers are not uncommon. Here there is no hint that the problematic ones are part-number like, but of course they may be. (Notoriously,. there are duplicate American SSNs, etc., and they can give rise to duplicate composite account numbers. Because duplicate data are common the designs sketched out here should be modified to include checks on the value of another datum that is unlikely to be in error. An example. One on-line medical-history database known to me contains 13 'John Walsh' patient records. So far DOBs disambiguate them, but good design will make provision for using a varying number of tests if and when they are needed for a particular ambiguous key value. [The word 'particular' is important here. Piling more tests on all transactions is a very bad idea, but it is a very common practice. Richard Jones knows he has a problem, and he is likely to be patient with questions about his DOB. Derek Tobias Parfit is likely to be less so.] John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
