Ограничение - это ключ, индекс - это ограничение?

Question

в SQL Server Management Studio (SSMS) 2008 R2 Dev на столе (потому что я не могу спросить без него)

--SET ANSI_NULL_DFLT_ON ON
create table B (Id int)

Я создаю уникальное ограничение

ALTER TABLE B
ADD CONSTRAINT IX_B
UNIQUE (ID)
WITH (IGNORE_DUP_KEY = ON)

SSMS показывает, что у меня нет никаких ограничений, но вместо этого есть ключ + индекс, в то время как контекстные опции (при щелчке правой кнопкой мыши) подсказывают мне создать (извините, скрипт) все еще ограничение.

ОСНОВНОЙ ВОПРОС:
Какой здесь ключ?
Зачем это нужно для этого ограничения?
Почему ограничение уникальности вызывается ключом (а ключ уникальностью)?
Извините, опять же, почему ключ вызывается индексом? Кажется, они имеют одно и то же имя (хотя, если бы я создал без явного имени, они бы назвали по-другому) ...
Извините, опять ...

ОБЗОРНЫЕ вопросы:
Какая функциональность отличается между «уникальным ограничением» и «уникальным индексом»? Я искал сегодня одну разницу (хотел найти 10) довольно долго и не смог ее найти.
Другими словами, для чего (почему) понятия (или конструкции) «уникальное ограничение» и «уникальный индекс» дублируются в SQL Server?

Бонусный вопрос (для тех, кому этот вопрос показался слишком простым):
Какой смысл в уникальном индексе (или в уникальном ограничении), разрешающем дублирование?

insert into B VALUES (1)
insert into B VALUES (1)
insert into B VALUES (1)

Обновление: Извините Спасибо, ребята и дамы (бонус снят)
Обновление 2: не было ли разницы между «уникальным индексом» и «уникальным ограничением» в предыдущем SQL Server (я смутно напоминаю, что один из них не разрешил NULL)?
Обновление 3: Действительно, меня всегда раздражало (смущало) «ограничение внешнего ключа», вызываемое «внешним ключом», хотя это не ключ, а ключ, внешний находится в другой таблице, внешний… и просто обнаружил, что это всеобщая путаница греметь на нем. По крайней мере, теперь я помню, что я должен помнить, напротив.

Update4:
@ Damien_The_Unbeliever , спасибо,
это, по крайней мере, некоторые уловки, чтобы запомнить замешательство.

Хотя, некоторые недоумения:
Почему эти кандидаты по умолчанию не равны NULL?

Изначально я действительно хотел вставить более короткий скрипт:

CREATE TABLE A(A INT UNIQUE);  

который произвел:

WTF этот "кандидат" на ПЕРВИЧНЫЙ и КЛЮЧ имеет синдром множественных идентичностей , тогда?
Разве «UQ_» не означает «Уникальное ограничение» в практике именования?

Теперь сценарий этого индекса UQ__A__3214EC262AA05119 создает ограничение без имени ... не индекса ... (?!):

ALTER TABLE [dbo].[A] ADD UNIQUE NONCLUSTERED 
(
    [ID] ASC
)
WITH 
(    PAD_INDEX  = OFF, 
     STATISTICS_NORECOMPUTE  = OFF, 
     SORT_IN_TEMPDB = OFF,
     IGNORE_DUP_KEY = OFF,
     ONLINE = OFF,
     ALLOW_ROW_LOCKS  = ON,
     ALLOW_PAGE_LOCKS  = ON) 
ON 
[PRIMARY]

WTheF - Как уникальный индекс определяется как ограничение? Где, чем

Сценарий ключа производит то же самое! опять же ограничение ... Почему это безымянно? Почему невозможно написать сценарий как «изменить», а только как «создать»?!
Это не имеет смысла!

Теперь, если выполнить сгенерированный скрипт, есть 2 dupes,
исполнить еще раз - вуаля: 3 одураченных "кандидата"

Примечание: если создать уникальное ограничение с помощью отдельного оператора T-SQL с пользовательским / ручным именем, как я сделал вверху, то сценарии не создают анонимный DML и, соответственно, их выполнение не позволяет умножать «кандидатов» "

Странные кандидаты на первичные ключи, не так ли? нужно посетить психотерапию (с множественными симптомами идентичности)?

Answer 1

УНИКАЛЬНОЕ ограничение также известно как ограничение УНИКАЛЬНЫЙ КЛЮЧ. В принципе, может быть несколько ключей для таблицы. Один выбран (несколько произвольно), чтобы быть ПЕРВИЧНЫМ КЛЮЧОМ для таблицы. Другие ключи создаются как ограничения UNIQUE KEY.

В качестве детали реализации ограничение UNIQUE KEY реализуется путем размещения индекса UNIQUE в тех же столбцах таблицы. Однако можно создать уникальные индексы для таблицы (через CREATE INDEX) без создания ограничения UNIQUE.

УНИКАЛЬНЫЕ ограничения похожи на ПЕРВИЧНЫЕ КЛЮЧИ - они могут быть целевой ссылкой для ограничения FOREIGN KEY. На УНИКАЛЬНЫЙ индекс сам по себе нельзя ссылаться.

В SSMS ограничения PRIMARY KEY, UNIQUE и FOREIGN KEY всегда будут отображаться в папке «Ключи» для таблицы. Ограничения CHECK и DEFAULT будут отображаться в папке «Ограничения»

Answer 2

Это только ответ на часть вашего вопроса, так как мне непонятно, почему Management Studio отображает эти объекты так, как оно делает.

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

Уникальный индекс (как и все индексы) - это деталь реализации, как и часть физической модели.

SQL Server использует уникальный индекс для реализации уникального ограничения.Есть логическое различие, и я думаю, что это проявляется в инструменте построения диаграмм SQL Server - если вы используете уникальное ограничение для внешнего ключа в отношении, которое в противном случае было бы отношением 1: n, оно отображается как 1: 1.Это не так при использовании уникального индекса (опять же, не уверен на 100%).

Answer 3

сначала все в вашей таблице есть только 1 значение, а не 3, посмотрите

create table B (Id int)


ALTER TABLE B
ADD CONSTRAINT IX_B
UNIQUE (ID)
WITH (IGNORE_DUP_KEY = ON)

insert into B VALUES (1)
insert into B VALUES (1)
insert into B VALUES (1)

- Дубликат ключа был проигнорирован.
- Дублированный ключ был проигнорирован.

select * from B

Один ряд, верно? Это потому, что у вас есть это (IGNORE_DUP_KEY = ON)

Теперь сделайте это

create table C (Id int)


ALTER TABLE C
ADD CONSTRAINT IX_C
UNIQUE (ID)


insert into C VALUES (1)
insert into C VALUES (1)

Второй ряд теперь не входит в таблицу

Способ, которым SQL Server реализует ограничение, заключается в том, что он создает за ним индекс для облегчения быстрого поиска среди прочего. Возможно, вам действительно нужен первичный ключ в этой таблице?

create table D (Id int not null primary key)

Answer 4

Уникальное ограничение реализовано внутри как индекс.

Практически единственное отличие между явным CREATE INDEX и добавлением ограничения через ALTER TABLE - это возможность иметь столбцы INCLUDE в качестве явного индекса.

SSMS несколько сбивает с толку, как это представляет.Понятия не имею, почему

Лично я считаю IGNORE_DUP_KEY бессмысленным и никогда не использовал его.

Указывает реакцию на ошибку при дублировании значений ключа в операции вставки из нескольких строк в уникальном кластерномили уникальный некластеризованный индекс.По умолчанию установлено значение OFF.

ON. Выдается предупреждающее сообщение, и только строки, нарушающие уникальный индекс, перестают работать.

OFF Выдается сообщение об ошибке и выполняется откат всей транзакции INSERT.

Параметр IGNORE_DUP_KEY применяется только к операциям вставки, которые происходят после создания или перестроения индекса.Настройка не влияет на работу с индексом.

Редактировать:

• Обнаружил это у меня раньше: Можно ли включить ignore_dup_key для основногоключ?

• Как правило, IGNORE_DUP_KEY имеет несколько ответов тоже