Primary key: code or name?

Question

One of the most common types of database tables has an alphanumeric code and a friendly human name (for example, countries, currencies, bills, products, VAT codes, etc.).

The traditional / obvious thing is to make the code a primary key. And for some tables, for example. customers, where the number can be large so that the names are not unique identifiers, this is certainly the right thing.

But what about countries such as countries and currencies where the number is guaranteed to be small and the names are guaranteed to be unique? In this case, the links will almost always be both input and displayed with a friendly name.

In this case, is there any reason not to specify the primary key name?

Answer 1

Never, never, use business value as a key.

Here's why: No matter how confident you are that the customer number is unchanged, sometimes the customer number will be changed in the future (the Chinese customer receives 4444, which is very unlucky, no matter what happens). If you used 4444 as a key, you will have to change not only the client’s key, but also the corresponding entries in his orders, his addresses, etc.

(Some argue that this can be resolved with cascading updates, but this is dangerous if there are triggers.)

: ID ( CustomerID). - , ( ), . , , .

, , GUID ( ).

: N-N (, , ). [CustomerID, AddressID] .

, , , /, , , .

Answer 2

... , ISO .

... , . -, , , .

/ , . , .

, , .

Answer 3

, , , . :

• numbers are faster to search than strings
• strings take up more memory than numbers