Зачем нужен первичный ключ?
Что проверяют
Понимаете ли вы первичный ключ как ограничение целостности, а не как «колонку id». Для тестировщика это ещё и вопрос о том, какие проверки из него следуют. Следом почти всегда спрашивают, чем первичный ключ отличается от уникального и от внешнего.
Как отвечать
Первичный ключ однозначно идентифицирует строку в таблице. Из этого следуют свойства:
- уникальность и NOT NULL: строку с повторяющимся ключом или без ключа база не запишет;
- один на таблицу: но он бывает составным, например
(order_id, product_id)в позициях заказа; - опора для связей: на него ссылаются внешние ключи, по нему
UPDATEиDELETEнаходят нужную строку; - индекс: СУБД создают под ключом уникальный индекс автоматически, а в MySQL InnoDB таблица физически упорядочена по первичному ключу.
Отличие от UNIQUE: уникальных ограничений может быть несколько, и они допускают NULL. В PostgreSQL несколько NULL в уникальной колонке считаются разными, если не указать NULLS NOT DISTINCT.
Про выбор ключа: суррогатный (IDENTITY, последовательность, UUID) не меняется вместе с бизнес-данными, а естественный (ИНН, номер паспорта) однажды может поменяться, и тогда придётся менять все ссылки.
Для QA отсюда вытекают проверки:
- повторный ключ: вставка существующего значения при импорте или синхронизации должна давать понятный ответ вроде 409, а не 500. Заметьте, суррогатный ключ от дублей по смыслу не спасает: две одинаковые заявки получат разные
id, для этого нуженUNIQUEна бизнес-полях; - удаление связанных данных: что происходит с зависимыми строками,
ON DELETE CASCADEили запрет; - перебор идентификаторов: если последовательный ключ виден в URL, проверьте, что
/orders/124не отдаёт чужой заказ.
Где спотыкаются
Говорят, что первичный ключ нужен «для скорости». Индекс это следствие, а смысл ключа в целостности.
Считают, что ключ обязательно число с автоинкрементом. Бывают UUID, составные и естественные ключи.
Путают первичный и внешний ключ или не могут объяснить отличие от UNIQUE, хотя это стандартный следующий вопрос.