What are the pros and cons of using the ISO currency code as the primary key of a database?

Question

Database design

I'm making a table with currencies "Currencies" using Sequelize ORM. What are the pros and cons. to use ISO currency codes as primary key instead of id:integer? How much will the size of the database increase after 10 years or more if you do not do this kind of normalization and take into account that each currency will be referenced daily by tens and hundreds of other records from other tables by foreign keys?

Answer 1

Don't use natural keys as primary keys. Use only surrogates. Avoid many problems.
There are two main problems with natural PCs.

1. Time passes, and it becomes necessary to change the natural key. For example, it was entered with an error (human factor). In your case, let's say the ISO decides that the existing code is not politically correct and needs to be changed. And you need to change either one row in one table, or all rows in all tables that refer to it. Feel the difference? And some of the data may already be in the archive, read-only, etc.
   
2. Time passes, and the "unique" natural key is not unique. For example, you need the same dollar, but with a special rate, etc. If this is a PC, then there is no normal solution, even if it is difficult, as in step 1. You will have to turn the natural key into a surrogate one, and add a separate column for the natural one. So it's better to do it from the beginning. :)
   

Answer 2

integer - 4 bytes
nvarchar(3) - three bytes (in theory)
So even save a little)

Answer 3

How much will the size of the database increase after 10 years

There are not so many currencies in the world, let it be up to a thousand. In 10 years, if you add another thousand, you won’t really feel it

Answer 4

primary - either int or uuid
https://www.percona.com/blog/2019/11/22/uuids-are-...
https://www.percona.com/blog/2015/04/03/illustrati ...
https://tomharrisonjr.com/uuid-or-guid-as-primary-...
the fact is that int can be iterated over, and this can be an essential way of protection, (well - overcoming type protection) - you can count a number users, for example, the number of records / items and anything
, but if not uuid - there will be a bunch of problems, with uniqueness and indexes, so for a visual non-numerical representation (like a string, although of course in the base it is the same binary as int) - only uuid
can be masked without hyphens and all that, of course I
’ll add about the Lentyuy dispute ,Vasily Bannikov and TS above: any schoolboy or at least an attentive student knows that strings are compared more slowly than numbers , but (!) When it comes to primary key, it's not just a string, it's an indexed string , and here everything is not so simple:
I'm too lazy look for an SO entry where they referred, as it were, not to Muskul himself with the words "but no difference", + to my shame, I don't remember whether it concerned strings or still uuid , but internally I'm sure that strings, in one project where there were max 2 million records were used in this way - so as not to be sparsed
as for billions of lines - then there, as at sublight speeds (and at supersonic speeds) - there are problems, at least, "write everything down and not lose it", "don't miss a backup or a shard", etc. etc. ., hence the column bases and so on and so
forth in short - within reasonable and millions of volumes (and in IRL there are only such, well, kanesh if we are not talking about time series / logs - again, other bases are used for this) - you can string primary key