А разве ICAO сам по себе не годится на роль натурального PK? Уникальный, короткий.

Изменение кодов ICAO повело бы к огромным неудобствам, поскольку они были придуманы как ключи, и с ними уже обращаются как с ключами (не только в БД, а в более широком смысле). Они не используютсе повторно.

Мне как раз предстоит принять очень похожее решение в другой области, и я собирался использовать уникальные и одноразовые международные коды в качестве натурального ключа. Они фиксированной длины и вроде бы подходят идеально, но тоже мной не контролируются, как Вы указали выше.

В чем состоит проблема внешнего контроля PK организацией? Возьмем например коды стран: допустим РФ по какой-то загадочной причине решит называться вместо "ru" - "rf". Подав петицию, после долгого период международного обсуждения, и при условии положительного решения, будет многомесячный, или даже многолетний период перехода. За это время мне придется добавить новую строку в таблицу стран, "rf, Russia", и обновить ссылки ru->rf. После чего пометить "ru" как удаленную и добавить сторожевой код на предмет попыток использования недействительного исторического ключа.

Звучит довольно несложно на мой взгляд не особо обремененный опытом проектирования БД.

Спасибо за подробный ответ.

Я сам не могу оценить риск такого решения, но проникся что вы настоятельно советуете против такого подхода.

Мне это чем-то напомнило реакцию молодых программистов когда речь заходит о временных поясах, или локализации. В России то все компы двуязычные, народ худо бедно в кодировках шарит.

Может тут дело ещё и не в ключе, а в монокультуре которая накладывает невидимые ограничения и стреножит мозг.

Мне интересно попробовать натуральные ключи в нескольких таблицах моего проекта, с ограничениями и преимуществами смысло-нейтральных целочисленных ключей я уже знаком. Они популярны, наверное эффективно реализованы почти везде.

С другой стороны, я бы лучше увидел != "'EUR" в коде чем
...!= 3 -- '3' это евро. Везде пишем троечку