индекс по сравнению с уникальным ключом в SQL Server 2008

Question

У меня есть следующая таблица, которая служит присоединиться к 3 таблицы:

ClientID int 
BlogID int 
MentionID int 

Если предположить, что запросы всегда будут поступать через ClientID, я могу создать 1 индекс нескольких столбцов (ClientID , BlogID, MentionID).

Вопрос в том, должен ли я создать его как кластерный индекс или уникальный ключ? Я понимаю, что кластерный индекс хранит данные на своих листовых узлах. Конечно, в этом случае индекс составляет данных, поэтому я не знаю, будет ли SQL Server дублировать данные или нет. Как бы то ни было, я не могу найти что-либо в MSDN о значении использования «уникального ключа».

Как это отличается от Type = Index & IsUnique = yes?

Может ли кто-нибудь сказать мне преимущества в каждом случае?

Answer 1

Кажется, вы просите разницу между:

MYTABLE 
id integer primary key autoincrement 
clientid integer 
blogid integer 
mentionid integer 
-- with a unique composite index on (clientid, blogid, mentionid) and three foreign key constraints 

и

MYTABLE 
clientid 
blogid 
mentionid 
-- with a composite primary key on (clientid, blogid, mentionid) and three foreign key constraints 

и

MYTABLE 
id integer primary key autoincrement 
    clientid integer 
    blogid integer 
    mentionid integer 
    with an index on clientid and also an index on blogid and the three foreign key constraints 

В первом, у вас есть индекс целочисленного первичного ключа а также альтернативный уникальный индекс на триаде. Если второй, у вас есть только уникальный индекс в триадном первичном ключе. В-третьих, у вас есть уникальный индекс для целочисленного первичного ключа и двух других неидеальных индексов, один на clientid и другой на blogid.

Увеличение производительности при незначительной большей эффективности второго варианта будет de minimis, и поэтому я бы основал решение по другим факторам. Третий является наиболее гибким с точки зрения запросов и предлагает большую простоту кодирования; он предлагает преимущества индексов на клиенте и в блоге, если вы хотите иметь запрос в блоге, а не в клиенте, в предложении WHERE. Что касается кодирования, некоторые инструменты GUI и промежуточное программное обеспечение имеют проблемы с первичными ключами с несколькими частями, и ваша логика обновления/вставки/удаления будет проще, когда она будет иметь дело с одним целым столбцом PK. Я обнаружил, что простота и простота обслуживания кода намного лучше, чем несколько секунд или всего лишь несколько секунд в секунду для улучшения времени ответа на запрос.

Answer 2

• unique index, unique key и unique constraint в основном то же самое. Они приводят к индексу , который обеспечивает уникальность.

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

Уникальные и сгруппированные неродственные свойства. Вы можете комбинировать их любым способом. Поэтому в вашем случае я бы создал уникальный кластеризованный индекс. Обычный способ сделать это - создать индекс как clustered primary key.

Answer 3

Данные будут не, если вы создадите уникальный кластерный индекс на трех столбцах.

Уникальный кластерный индекс быть данных - и индекс в то же время :-)

Поскольку это трехходовой присоединиться к таблице, это кластерный индекс, вероятно, делает много смысла. Я бы сказал: пойдите для этого!

Answer 4

Кластерный индекс - это «сама таблица», то есть узлы индекса расположены в дереве, а его листовые узлы содержат данные строки. Кластеризованный индекс не должен быть объявлен уникальным (хотя обычно это); если он не уникален, сервер неявно добавляет «uniqalizer» к этому индексу, так что каждая строка уникально идентифицируется.

Другие индексы хранят кластерное значение индекса как их листовые узлы (и, возможно, некоторые другие столбцы, если они включены в предложение INCLUDE в CREATE INDEX staetment).

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

Answer 5

и UNIQUE CONSTRAINT несколько иные понятия.

• UNIQUE CONSTRAINT является логическим понятием и означает «убедитесь, что этот столбец не является уникальным, независимо от того, как»
• UNIQUE INDEX является физическим понятием и означает «создать B-Tree индекс по этой колонке и не всякий раз, когда дублирует вставлены там "

Последнее подразумевает первое, но не наоборот.

Например, в Oracle, если у вас есть не уникальный индекс на col1:

• CREATE UNIQUE INDEX (col1) подведет и сказать «эти колонки уже проиндексированы»
• ALTER TABLE ADD CONSTRAINT UNIQUE(col1) будет успешным и использовать существующий индекс для полицейских ограничений.

Используйте CONSTRAINT, если вы просто хотите, чтобы столбец быть уникальным и INDEX, если вы знаете B-Tree индекс, что вы хотите (для ускорения поиска и т.д.).