Первичный ключ как текст - программирование

В курсе баз данных, который я делал во время моего образования (около 4 лет назад), я думал, что рекомендуется избегать использования символьных строк в качестве типа данных первичного ключа.

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

N.B.: (Я использую базу данных PostgreSQL). Я также имею дело с ситуацией, когда вам нужно ссылаться на такую таблицу на другую, тем самым помещая внешний ключ на характер различного типа данных. Пожалуйста, учтите, что также.

Ответ 1

Преимущества для выбора типа символьного символа в качестве поля первичного ключа - это то, что вы можете выбрать, какие данные он может отобразить. Например, вы могли бы указать адрес электронной почты в качестве ключевого поля для таблицы пользователей. Это устраняет необходимость в дополнительном столбце. Другим преимуществом является наличие общей таблицы данных, содержащей индексы нескольких других таблиц (считайте таблицу NOTES с внешней ссылкой на таблицы FINANCE, CONTACT и ADMIN), вы можете легко узнать, из какой таблицы это произошло (например, ваша таблица FINANCE имеет индекс F00001, таблица CONTACT имеет индекс C00001 и т.д.). Боюсь, что недостатки в этом ответе будут более значительными, поскольку я против такого подхода.

Недостатки заключаются в следующем:

Серийный тип данных существует именно по этой причине в PostgreSQL
Числовые индексы будут введены по порядку, и нужно будет выполнить минимальное переиндексацию (т.е. если у вас есть таблица с ключами Apple, морковью и хотите вставить Banana, таблица должна будет перемещаться по индексам так, чтобы банана была вставлена в середине. Вы редко вставляете данные в середине индекса, если индекс является числовым).
Числовые индексы, не привязанные к данным, не будут меняться.
Числовые индексы короче и их длина может быть исправлена (4 байта по сравнению с тем, что вы выбираете в качестве длины вашего varchar).

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

Это обычные стандарты при написании SQL, но когда дело доходит до бенчмаркинга, вы обнаружите, что столбцы varchar немного медленнее при объединении и фильтрации, чем целые столбцы. Пока ваши первичные ключи не меняются КАЖДОЕ, тогда вы в порядке.