Я всегда пытался иметь целочисленный первичный ключ на таблице несмотря ни на что. Но теперь я подвергаю сомнению, необходимо ли это всегда.
Скажем, у меня есть таблица product, и каждый продукт имеет глобально уникальное число SKU - который был бы строкой, говорят 8-16 символов. Почему бы не сделать это PK? Обычно я сделал бы это поле уникальным индексом, но затем имел бы автоматическое увеличивающее международное поле как PK, поскольку я предположил, что это будет быстрее, легче поддержать и позволило бы мне делать, вещам нравится, получают последние 5 записей, добавленных легко.
Но с точки зрения оптимизации, принимая я только когда-либо соответствовал бы полнотекстовому полю и затем делал бы текст, соответствующий запросам (например, как %%) может Вы парни думать о каких-либо причинах не использовать основанный на тексте первичный ключ, скорее всего, типа varchar ()?
С наилучшими пожеланиями, imanc
Использование номера SKU в качестве первичного ключа имеет определенный смысл. Вы захотите проиндексировать его, чтобы ускорить поиск по артикулу. А SKU - это натуральный индекс .
Однако он имеет некоторые недостатки:
Производительность (как сказал Коронатус)
Отсутствие гибкости дизайна. Если по какой-либо причине SKU перестает быть глобально уникальным, вы будете вынуждены изменить не только структуру таблицы, но и все ваши запросы.
Изменение SKU одного элемента заставит вас изменить все отношения в базе данных.
Компьютеры НАМНОГО быстрее сравнивают числа, чем строки.
Кроме того, индексы строк MySQL по умолчанию содержат только первые 4 буквы.
Если у вас есть строки blabfoo, blabbar, blabboo
, индекс будет совершенно бесполезен, потому что первые 4 символа равны, поэтому поиск «blabf» первоначально будет соответствовать ВСЕМ 3 строкам, а затем повторяться результаты, достижения.
По сути, никогда не используйте строки для индексов, потому что они медленные и занимают больше места.