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

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

4 голосов
/ 10 ноября 2011

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

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

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

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

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

1 Ответ

3 голосов
/ 10 ноября 2011

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

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

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

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

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

...