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

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

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

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


sql primary-key foreign-keys sqldatatypes postgresql-9.1
person artaxerxe    schedule 18.03.2013    source источник
comment
Некоторое понимание можно найти здесь: stackoverflow.com/questions/337503/   -  person Sami N    schedule 18.03.2013
comment
stackoverflow.com/questions/404040 /   -  person Damir Sudarevic    schedule 18.03.2013

Ответы (1)


arrow_upward
27
arrow_downward

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

К недостаткам можно отнести следующие:

  1. Последовательный тип данных существует именно по этой причине в PostgreSQL.
  2. Числовые индексы будут вводиться по порядку, и потребуется минимальная переиндексация (т.е. если у вас есть таблица с ключами Apple, Carrot и вы хотите вставить Banana, таблица должна будет перемещаться по индексам так, чтобы Banana был вставлен посередине. Вы редко будете вставлять данные в середину индекса, если индекс является числовым).
  3. Отключенные от данных числовые индексы не изменятся.
  4. Числовые индексы короче, и их длина может быть фиксированной (4 байта по сравнению с тем, что вы выберете в качестве длины varchar).

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

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

person DF_    schedule 18.03.2013
comment
таблица должна будет перемещаться по индексам так, чтобы банан был вставлен посередине Эта информация неверна, особенно потому, что OP упомянул PostgreSQL, который не упорядочивает записи в соответствии с к первичному ключу. См .: stackoverflow.com/a/13191075/517371 - person Tobia; 22.06.2016
comment
@Tobia Правильно, но на плакате прямо говорится о перемещении по указателям. Очевидно, что записи в указателях упорядочены. - person enobayram; 28.08.2019