Hello Ongoma,
in general, I'd rather introduce some autoincrementing number field to any table as a primary key, you may still have a candidate index on combined fields just to check data integrity, but for joins and seeks the single field will normally be more comfortable. An exception are tables that build up an n:m relationship of two other tables. often then you might want to view it from the n or m side and join on each single foreign key. But even then you may have those two foreign key fields in the crossreferencing table and an additional own primary key.
Theory also states, that a primary key should have no meaning whatsoever, besides being a unique key for that record, that can be referenced as a foreign key in a child table. So a primary key should just be some numbering or even something random thing like a GUID.
And Candidate index type is there to have the check on uniqueness as some kind of data integrity check additional to some fully unrelated primary key.
Then, if you come into the situation, that the key does not really need to be unique, it's quite easy to change it to a regular index or even drop it, if that uniqueness check is all the index was made for.
I wouldn't even use an email or phone number or postal code as a primary key, although the nature of such things is to be unique.
The main aspect of defining a primary key is to be unique, but you shouldn't search for a data field or a combination of fields in the record that is/are unique, simply introduce an extra ID field for the primary key. You can't go wrong.
Bye, Olaf.