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

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

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

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

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

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

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

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

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

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

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

[quot ChA#22323507]

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


По поводу компактности и скорости я был удивлен когда начал изучать SQL в прошлом году что в Оракле база данных не поддерживает хранение целых чисел, а за целые числа выдаются числа с плавающей точкой и переменной длины мантиссы (!!!!). У них длина в первом байте где-то.

Насколько я помню ассемблер, такие числа сравнивать то же самое, что паскальные строки.

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