Первичные ключи в базе данных журналов - PullRequest
2 голосов
/ 07 мая 2011

Я создаю базу данных, которая будет регистрировать использование ПК.Будет несколько записей в формате: Компьютер, Пользователь, AuditTime.Он предназначен для отслеживания того, кто был зарегистрирован на каком компьютере во время аудита.Справочные таблицы компьютеров и пользователей всех компьютеров и пользователей в нашей компании и соответствующих подразделениях.

Должен ли я сделать Computer и AuditTime вместе составным ключом?Есть ли потеря производительности при выигрыше от задания первичного ключа, когда на самом деле уникальное ограничение для этой таблицы не требуется?

База данных MS SQL Server 2008.

Ответы [ 2 ]

3 голосов
/ 07 мая 2011

SQL Server делает ваши первичные ключи вашими ключами кластеризации по умолчанию (если вы не указали этого специально), и, как показывает Кимберли Трипп в своем блоге Дебаты по кластерному индексу продолжаются , когда кластерный индекс включентаблица полезна для любой операции, включая INSERT и DELETE, при условии, что это кластеризованный индекс правильный .

Хороший кластеризованный индекс должен быть:

  • узкий
  • уникальный
  • стабильный (без изменений)
  • постоянно увеличивающийся

Лучше всего подойдет INT IDENTITY суррогатный ключ -Я бы посоветовал против составных индексов в подавляющем большинстве случаев.

3 голосов
/ 07 мая 2011

Редактировать : проголосовать за Marc_s!

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

...