Нужен ли столбец идентификатора в таблице аудита?

Question

Многие табличные конструкции, которые я вижу вокруг, имеют столбец id в качестве первичного ключа. Например, log_id в некоторой таблице Logging, event_id в некоторой таблице событий и так далее. Этот столбец не будет зависеть от любого другого столбца в любой другой таблице и однозначно идентифицирует запись. С точки зрения просмотра часто, когда столбцы, используемые для поиска информации, представляют собой другие столбцы в таблице, которые также могут быть проиндексированы (status/event_type/etc и т. Д.). Итак, какова необходимость иметь такой столбец идентификатора, представляющий запись в таблице? Если я должен удалить такой столбец идентификаторов из таблицы журналов и вместо этого использовать комбинированный ключ, какое преступление я совершу? Почему такая распространенная практика имеет такой уникальный столбец идентификатора в таблице, где иначе этот столбец не используется в приложении? В надежде услышать мнения экспертов. : o

ОБНОВЛЕНИЕ: Благодарим всех за быстрые ответы! Прежде всего, я хотел бы понять, почему такая обычная практика заключается в использовании суррогатного ключа вместо составного ключа в таблицах, таких как таблицы аудита (есть и другие примеры, но попытка сосредоточиться на разговоре). В такой таблице я мог бы легко идентифицировать уникальную запись, комбинируя событие, идентификатор пользователя и временную метку. Тем не менее, большинство проектов, которые я исследовал в Интернете, используют такие ключи, как event_id. Я пытаюсь понять, почему, если есть какая-то настоящая причина? На самом деле, не означает ли это, что потребляет ненужное хранение db?

Answer 1

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

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

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

Answer 2

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

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

Это разложение денормализует таблицы, плюс эти значения могут меняться. Как? Наиболее распространенным является потому, что они были введены неправильно, в первую очередь, но у меня есть клиент, который должен был изменить SSN для следующих дополнительных причин:

• Клиент получил новый номер социального страхования из-за кражи личных данных.
• Клиенты, которые были «недокументированы» и использовали поддельные SSN, затем стали «документированными» и получили реальные SSN.
• Большая: исполнительный аппарат, в котором все SSN должны храниться в зашифрованном виде.

К счастью, по моему совету (и советам других), они не использовали SSN как часть своего первичного ключа, поэтому эти изменения были легкими.

Другая причина, по которой избегать составных клавиш: они добавляют сложность к JOIN. Но опять же, с журналом аудита, вам, вероятно, все равно.

Наконец, я хочу подчеркнуть, что я использую значения типа ID почти в 100% случаев и делаю это уже более десяти лет, так что это не случай, когда я являюсь двойственным к составным клавишам.Я стараюсь избегать их, но опять же в вашем случае я не думаю, что это плохо.

Answer 3

В дополнение к другим ответам, я думаю, что еще один вопрос, который стоит иметь в виду, - это то, какую уникальность вам нужно учитывать. Если вам требуется, чтобы составной ключ оставался уникальным, есть два варианта: 1) создать композит как ПК или 2) использовать суррогатный ключ (сгенерированный системой номер) и добавить еще один альтернативный ключ на составной (естественный ключ). Это иногда диск, который я использую. Диана

Answer 4

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

Эти таблицы, которые не имеют Естественный ключ - т. Е. Нет комбинации столбцов, которые могут быть гарантированы уникальными, но дубликаты имеют смысл; и нет даже теоретического, логического естественного ключа, который может быть применен. Другими словами, это не реальное отношение к реляционной модели данных. Мы просто используем таблицу для удобства.

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

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

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