Какие за и против использования ISO кода валют в качестве первичного ключа базы данных?

Question

[Евгений Заливадный]

Делаю таблицу с валютами "Currencies" с помощью Sequelize ORM. Какие за и против того. чтобы использовать ISO коды валют в качестве первичного ключа вместо id:integer? Насколько сильно увеличится размер БД спустя 10 лет или более, если не делать такого рода нормализацию и учитывать что на каждую валюту будут ежедневно ссылаться десятки и сотни других записей из других таблиц по внешним ключам?

Answer 1

[ComodoHacker]

Не используйте естественные ключи в качестве первичных. Используйте только суррогатные. Избежите многих проблем.

Основных проблем с естественными ПК две.

1. Проходит время, и возникает необходимость поменять естественный ключ. Например, его внесли с ошибкой (человеческий фактор). В вашем случае, допустим ISO решила, что существующий код оказывается не политкорректный, и его нужно поменять. И вам нужно поменять либо одну строку в одной таблице, либо все строки во всех таблицах, которые на нее ссылаются. Чувствуете разницу? А часть данных может быть уже в архиве, read-only и т.д.
   
2. Проходит время, и "уникальный" естественный ключ оказывается не уникальным. Например, вам понадобился тот же доллар, но с особым курсом и т.п. Если это ПК, то нормального решения нет, пусть даже сложного, как в п. 1. Вам придется превратить естественный ключ в суррогатный, а для естественного добавить отдельный столбец. Так лучше сделать это с самого начала. :)
   

Answer 2

[Василий Банников]

integer - 4 байта
nvarchar(3) - три байта (по идее)
Так что даже немного сэкономите)

Comments

[Василий Банников]

Лентюй, на столько ли медленнее?

[Евгений Заливадный]

Интересно... а Integer такой прожорливый, потому что в любом случае занимает место под 2147483647, даже если оперируем 0 или 1?

[Евгений Заливадный]

Лентюй, а если в цифрах? И как можно замерить эту скорость? Нужно также учитывать, что при выборке по числу придётся перед этим делать дополнительную выборку для получения этого числа, если заранее его не знаешь.

[maksam07]

Eugene Z, сделайте тест. Создайте 1000 фейковых валют и и миллион+ строк в другой таблице, где ячейка будет ссылаться на валюту. Поиск скорее всего в любом случае будет происходить быстро, потому что в таблице валют довольно мало строк

[Василий Банников]

Лентюй, ок, не знал

[Василий Банников]

Eugene Z, да.
Но есть и более мелкие типы данных, названия которых зависят от вашей субд

[ComodoHacker]

Eugene Z, Место занимаемое числовыми значениями, зависит от определения типа столбца и от реализации в конкретной СУБД. В некоторых предусмотрены разные числовые типы с разной размерностью. В некоторых тип один, но размер в байтах зависит от значения.

Answer 3

[maksam07]

Насколько сильно увеличится размер БД спустя 10 лет

Валют в мире не так много, пусть будет до тысячи. За 10 лет если добавишь еще тысячу, то особо этого не почувствуешь

Comments

[Евгений Заливадный]

вы не поняли, большое количество записей будет не в таблице валют, а в ссылающихся на них таблицах

Answer 4

[Dimonchik]

первичный - или int или 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-...

дело в том что int можно перебрать, и это бывает существенным способом защиты, (ну - преодоления защиты типа) - можно считать число юзеров, например, число записей/айтемов и чего угодно

а вот если не uuid - там будет своя пачка проблем, с уникальностью и индексами, так что для визуального нечисленного представления (типа строка, хотя конечно в базе это такой же binary как и int) - только uuid
можно масировать его без дефисов и все такое, само собой

добавлю про спор Лентюй , Василий Банников и ТС выше: любой школьнег или хотя бы внимательный студент знает что строки сравниваются медленнее чисел , но(!) когда речь о primary key -это не просто строка, это проиндексированная строка, и вот тут же не все так однозначно:
мне лень искать SO запись, где ссылались как бы не на сам Мускуль со словами "а никакой разницы", + к своему стыду, я не помню, касалось это строк или все же uuid, но внутренне уверен что строк, в одном проекте где было макс 2 млн записей именно так и использовали - чтобы не спарсили
что касается миллиардов строк - то там, как на досветовых скоростях (да и на сверхзвуковых) - свои проблемы, как минимум, "все записать и не потерять", "не прос*рать бэкап или шард" и т.д и т.п., отсюда колоночные базы и проч и проч
короче говоря - в пределах разумного и миллионных объемов ( а в IRL только такие и есть, ну , канеш если мы не про временнЫе ряды / логи - опять же, для такого другие база используют) - можно строковый primary key