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

Question

Неужели так плохо использовать "varchar" в качестве первичного ключа?

(будет хранить пользовательские документы, и да, он может превышать 2+ миллиардов документов)

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

1. int можно сравнить с меньшим количеством инструкций процессора (запросы соединения ...)
2. int упорядочен по умолчанию ->сбалансированное дерево индексов -> без реорганизации, если вы используете PK в качестве кластерного индекса
3. для индекса требуется потенциально меньше места

Answer 5

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

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