>I have a table in which no single field uniquely identifies a record. It seems that to identify each record uniquely I need to concatenate several fields together to form a unique key. Is it best to use this concatenated key as the primary index or should I add another field to each record and put an abstract unique value in it and then use that as the primary index?

First, a short answer, and then some examples: If there is a rule that states that the key fields may appear together only once, then I use the concatenation; otherwise, I might use an abstract key.

For example, suppose I have three "master" tables (ARTICLES, SIZES, OPTIONS) and a "slave" table (COSTS) with fields ARTICLE_ID, SIZE_ID, OPTION_ID and COST. (Each record could mean that article ARTICLE_ID, in size SIZE_ID, with option OPTION_ID, costs COST.) I do not want to have TWO possible costs for the same article, size and option, so if I use an abstract key I´ll have to check manually for duplicates.

On the other hand, I might have an ORDERS table with fields ORDER_NUMBER, ARTICLE_ID and QUANTITY_ASKED. If in the same order a customer asked for a certain article and then asked for it again, I would have no objections to having two different records with the same ORDER_NUMBER and ARTICLE_ID (and even the same QUANTITY_ASKED), so I could do with an abstract key. (Whether I would actually opt for that or not is another question.)

Summing up: in the first case, there was a rule which stated that each combination might appear only once, so I made that combination a primary key. In the second case there was no such rule, so an abstract key was possible.

HTH!