Использование "varchar" в качестве первичного ключа? плохая идея? или нормально?

Ответ 1

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

Ответ 2

Если вы собираетесь присоединяться к другим таблицам, varchar, особенно широкий varchar, может быть медленнее, чем int.

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

Далее многие возможные varchar Pks на самом деле не уникальны, и иногда они кажутся уникальными (например, номера телефонов), но могут быть повторно использованы (вы отказываетесь от номера, телефонная компания переназначает его), а затем дочерние записи могут быть прикреплены к не то место. Поэтому перед использованием убедитесь, что у вас действительно уникальная неизменная ценность.

Если вы решите использовать суррогатный ключ, сделайте уникальный индекс для поля varchar. Это дает вам преимущества более быстрого объединения и уменьшения количества записей для обновления, если что-то меняется, но сохраняет тот уникальный, который вы хотите.

Теперь, если у вас нет дочерних таблиц, а probaly никогда не будет, большая часть этого будет спорным и добавление целого числа pk - это просто пустая трата времени и пространства.

Ответ 3

Я думаю, что int или bigint часто лучше.

• int можно сравнить с меньшими инструкциями CPU (присоединить запросы...)
• последовательность int упорядочена по умолчанию → сбалансированное дерево индексов → отсутствие реорганизации, если вы используете PK в качестве кластерного индекса
• индекс нуждается в потенциально меньшем пространстве

Ответ 4

Я понимаю, что я немного опаздываю на вечеринку здесь, но подумал, что было бы полезно немного доработать предыдущие ответы.

Не всегда полезно использовать VARCHAR() в качестве первичного ключа, но он почти всегда есть. До сих пор я не встречал времени, когда я не мог найти более подходящее поле первичного ключа фиксированного размера.

VARCHAR требует больше обработки, чем целое число (INT) или короткое фиксированное поле длины char (CHAR).

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

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

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

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

Ответ 5

Используйте идентификатор (это станет удобно, если вы хотите показать только 50 и т.д.). Затем установите ограничение UNIQUE на ваш varchar с именами файлов (я полагаю, это то, что вы храните).

Это сделает трюк и увеличит скорость.