Nordihan
@Nordihan
JAVASCRIPTIZER (REACT / NODE.JS)

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

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

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

если не делать такого рода нормализацию

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

Валют в мире не так много, пусть будет до тысячи. За 10 лет если добавишь еще тысячу, то особо этого не почувствуешь
Ответ написан
dimonchik2013
@dimonchik2013
совет, который уже дан - ничего не стоит
первичный - или 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
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы