VARCHAR как внешний ключ/первичный ключ в базе данных хорошо или плохо?

Лучше ли использовать ID nr: s вместо VARCHARS в качестве внешних ключей? И лучше ли использовать ID nr: s isntead VARCHARS в качестве Первичных ключей? По ID nr я имею в виду INT!

Это то, что у меня есть сейчас:

category table:
cat_id ( INT ) (PK)
cat_name (VARCHAR)

category options table:
option_id ( INT ) (PK)
car_id ( INT ) (FK)
option_name ( VARCHAR )

Я МОЖЕТ БЫТЬ ЭТО, ЧТО Я ДУМАЮ:

category table:
cat_name (VARCHAR) (PK)

category options table:
cat_name ( VARCHAR ) (FK)
option_name ( VARCHAR ) ( PK )

Или я думаю здесь совершенно неправильно?

Ответ 1

Проблема с VARCHAR, используемая для любого KEY, заключается в том, что они могут содержать WHITE SPACE. Белое пространство состоит из ЛЮБОГО, не просматриваемого на экране символа, таких как вкладки пробелов, возврата каретки и т.д. Использование VARCHAR в качестве ключа может затруднить вашу жизнь, когда вы начинаете выслеживать, почему таблицы не возвращают записи с дополнительными пробелами в конце их ключей.

Конечно, вы CAN используете VARCHAR, но вам нужно быть очень осторожным с вводом и выводом. Они также занимают больше места и, вероятно, медленнее при выполнении запросов.

Целочисленные типы имеют небольшой список из 10 символов, которые действительны, 0,1,2,3,4,5,6,7,8,9. Это гораздо лучшее решение для использования в качестве ключей.

Вы всегда можете использовать ключ на основе целых чисел и использовать VARCHAR как значение UNIQUE, если вы хотите иметь преимущества более быстрого поиска.

Ответ 2

Мои 2 цента:

С точки зрения производительности использование CHAR или VARCHAR в качестве первичного ключа или индекса - это кошмар.

Я тестировал составные первичные ключи (INT + CHAR, INT + VARCHAR, INT + INT), и, безусловно, INT + INT был лучшей производительностью (загрузка хранилища данных). Допустим, что в два раза больше производительности, если вы сохраняете только числовые первичные ключи/индексы.

Ответ 3

Когда я занимаюсь проектной работой, я спрашиваю себя: есть ли у меня что-нибудь в этих данных, которое я могу гарантировать, будет не-NULL, уникальным и неизменным? Если это так, чтобы кандидатом был первичный ключ. Если нет, я знаю, что мне нужно создать ключевое значение для использования. Предполагая, что мой ключ-кандидат оказывается VARCHAR, я затем просматриваю данные. Является ли он достаточно коротким по длине (что означает, скажем, 20 символов или меньше)? Или поле VARCHAR довольно длинное? Если коротко это использовать в качестве ключа - если он длинный, возможно, лучше не использовать его в качестве ключа (хотя, если рассматривать его как первичный ключ, мне, вероятно, придется индексировать его в любом случае). По крайней мере, часть моей озабоченности заключается в том, что первичный ключ должен быть проиндексирован и, возможно, будет использоваться в качестве внешнего ключа из какой-либо другой таблицы. Сравнение полей VARCHAR, как правило, медленнее, чем сравнение числовых полей (в частности, двоичных числовых полей, таких как целые числа), поэтому использование длинного поля VARCHAR в качестве ключа может привести к низкой производительности. YMMV.

Ответ 4

Я бы сказал, что использовать VARCHAR как PRIMARY и FOREIGN KEYS хорошо.

Единственный вопрос, который я мог предвидеть, - это если у вас есть таблица, скажем, инструменты (общие инструменты), и вы создаете PRIMARY/FOREIGN KEY как VARCHAR, и бывает, что CODE изменяется.

Это происходит на биржевых биржах и потребует от вас переименования всех ссылок на этот КОД, где, поскольку ID nr не потребует этого от вас.

Таким образом, я бы сказал, что это зависит от вашего предполагаемого использования.

ИЗМЕНИТЬ

Когда я говорю CODE, я имею в виду код Ticker, который позволяет говорить GOOG или любую другую. Эти коды могут меняться со временем, скажем, вы смотрите на инструменты Dirivative/Future.

Ответ 5

Если вы укажете имя категории в идентификатор, у вас возникнет проблема, если вы когда-нибудь решите переименовать категорию.

Ответ 6

с int вы можете хранить до 2 миллиардов в 4 байтах с varchars, вам не нужно иметь 10 байт или около того, чтобы сохранить это, если вы используете varchars, есть также 2-байтовые служебные

так что теперь вы добавляете 6 дополнительных байтов в каждом PK и FK + 2 байта служебных данных varchar

Ответ 7

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

Если вы используете CHAR или VARCHAR в качестве первичного ключа, вы в конечном итоге будете использовать его как символ forign. Когда дело доходит до этого, как говорит @astander, это зависит от ваших данных и от того, как вы собираетесь их использовать.