#sql #sql-server #sql-server-2008 #logging #primary-key
#sql #sql-сервер #sql-server-2008 #протоколирование #первичный ключ
Вопрос:
Я создаю базу данных, которая будет регистрировать использование ПК. Там будет несколько записей формата: Компьютер, Пользователь, Время проверки. Это для отслеживания того, кто на каком компьютере входил в систему во время выполнения аудита. Справочные таблицы компьютеров и пользователей всех компьютеров и пользователей в нашей компании и их соответствующих отделах.
Должен ли я сделать Computer и auditTime вместе составным ключом? Есть ли снижение производительности или выигрыш от указания первичного ключа, когда на самом деле ограничение уникальности в этой таблице не требуется?
Базой данных является MS SQL Server 2008.
Ответ №1:
SQL Server по умолчанию делает ваши первичные ключи ключами кластеризации (если вы специально не укажете ему не делать этого), и, как показывает Кимберли Трипп в своем блоге, обсуждение кластеризованного индекса продолжается, наличие кластеризованного индекса в таблице полезно для любой операции, включая ВСТАВКУ и УДАЛЕНИЕ, при условии, что это правильный тип кластеризованного индекса.
Хороший кластеризованный индекс должен быть:
- узкий
- уникальный
- стабильный (без изменений)
- постоянно растущий
Наилучшим вариантом был бы INT IDENTITY суррогатный ключ — в подавляющем большинстве случаев я бы не советовал использовать составные индексы.
Комментарии:
1. и рассмотрите bigint, если есть шанс выйти за пределы пары миллиардов строк … проще сделать это заранее, чем изменять.
2. Спасибо за вашу помощь. Я выберу int, поскольку мы будем очищать журналы, которым более ~ 400 дней, и это приводит нас всего к паре сотен тысяч. Это суррогатный идентификатор int.
Ответ №2:
Редактировать: Голосуйте за Marc_s!
Наличие первичного ключа снижает производительность — вот почему они обычно не настраиваются в таблицах с высокой вставкой и низким использованием чтения (Т. Е. в журналах). Но кластеризованный ключ хорош.
Комментарии:
1. Не совсем верно — преимущество наличия кластеризованного ключа (и, следовательно, кластеризованной таблицы по сравнению с кучей) на самом деле превосходит любой недостаток PK
2. @marc_s: Спасибо — Я по умолчанию использую Oracle, никакой ерунды с кластеризованными ключами: p
3. но КУРСОРЫ ССЫЛОК и тому подобное — вместо хороших наборов результатов — из сохраненного процесса ….. у каждой системы свои «шипы» и «бородавки» 🙂
4. @marc_s: Пакеты Oracle > Сборки SQL Server или, безусловно, автономные процедуры / функции. И синтаксис PLSQL намного чище — TSQL похож на VB: p
5. @marc_s: В свою защиту могу сказать, что я мало что знаю о Oracle до 9i