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

теперь по существу.

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

тут откуда не возьмись -... понадобилось переназначить айдишники файлам :) изза отсутсвия привязки к этому гуиду, на шдд ничего менять не надо!

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


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

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

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

когда сможете опротестовать первое, будете без примари кея делать.

ЗЫ
это не ответ отмазка, оно так и есть, надо всегда. когда вы столкнётесь с опытом с ситуаций где допустимо иначе, сами поймёте это.
пока же возникают сомнения - всегда да, всегда автоназначаемое

Alicedz0dium,
"иметь отдельную таблицу-справочник с уникальным индексом по текстовому полю и хранить в основной таблице id из справочника?"

Если вас не беспокоит большой размер БД и производительность поиска по длинному ключу, то необязательно. Хотя все зависит от количества и качества данных.

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

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

с точки зрения производительности, в основной таблице на подмилион записей скажем(или основных таблиц) - легче хранить поле в один-два байта или цепочку в 20(или в 40 байт если двухбайтная кодировка) - а индекс строить на какое поле легче...

вся логика обработок статистик, агрегации данных итд легче делать по числовому ключу, тем более короткому(1-2 байта) чем по строке длинной.

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

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