Candidate Key

Techopedia explains Candidate Key

The best way to define candidate keys is by using an example. Say, a bank’s database is being designed. To uniquely define each customer’s account, a combination of the customer’s ID or social security number and a sequential number for each of his or her accounts can be used. So, Mr. Andrew Smith’s checking account can be numbered 2233344-1, and his savings account 223344-2. A candidate key has just been created.

This can raise some problems. What if the government makes a mistake and issues the same social security number to more than one person and both of them now want to open an account with the bank?

Because of such potential pitfalls, one frequently used option is to create your own candidate key. In this case, the bank’s database can issue unique account numbers that are guaranteed to avoid the problem just highlighted. For good measure, these account numbers can have some logic built in. For example checking accounts can begin with a ‘C’, followed by the year and month of creation, and within that month, a sequential number. So Andrew Smith’s checking account can now be C-200805-22. Even without referring elsewhere, a teller can tell that this was the 22nd checking account created in May 2008. Savings account can follow the same logic, but with an ‘S’ instead of ’C’.

Note that it was possible to uniquely identify each account using the aforementioned social security numbers and a sequential number (assuming no government mess-up in which the same number is issued to two people). So this is a candidate key that can potentially be used to identify records. However, a much better way of doing the same thing has just been demonstrated -- creating a candidate key. In fact, if the chosen candidate key is so good that it can certainly uniquely identify each and every record, then it should be used as the primary key. All databases allow the definition of one, and only one, primary key per table.