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

Question

Хотя я некоторое время работал с запросами к базам данных SQL, я все еще довольно новичок в создании хороших таблиц. Я часто борюсь с первичными ключами.

В таблице, которую я сейчас создаю для регистрации ошибок на некоторых устройствах сигнализации, мне нужно 5 столбцов. park а также code столбцы однозначно идентифицирует сайт (хотя park колонка атм. не используется). Тогда есть serial колонка с указанием оборудования и error содержащий код ошибки. Наконец, есть timestamp когда ошибка регистрируется.

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

Таким образом, чтобы однозначно идентифицировать ошибку, нам нужно проверить park, code, serial а также fault, Все это кажется хорошими кандидатами для индексов, основанных на запросах, которые могут быть выполнены. Однако мне кажется неправильным определять все это как объединенный первичный ключ, ведь это почти все столбцы в таблице!

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

Answer 1

Многие люди просто скажут вам добавить идентификационный номер в эту таблицу и сделать его первичным ключом.

Я не один из тех людей.

Если столбцы {park, code, serial, fault} необходимы для уникальной идентификации строки и, таким образом, для предотвращения дублирования, то dbms должен это знать. Вы сообщите БД об этом требовании одним из двух способов.

• ПЕРВИЧНЫЙ КЛЮЧ (парк, код, серийный номер, неисправность)
• NOT NULL UNIQUE (парк, код, серийный номер, ошибка)

В некоторых случаях имеет смысл использовать меньший суррогатный ключ (идентификационный номер) в качестве первичного ключа. Это не освобождает вас от ответственности за информирование БД об истинном положении дел. (С NOT NULL UNIQUE (park, code, serial, fault).) Я не думаю, что это относится к вашей ситуации, хотя.