GlorySandalTreeТам какой-то потаённый смысл в 2-х одинаковых индексах или это просто баг?
Я вам про это уже говорил
Primary KEY, Unique Constraint - это только _декларация_
Грубо говоря, только запись в списке объектов, которая ссылается на другой _физический_ объект.
Физическим же объектом для этих ограничений всегда является индекс.

Ваши два вопроса с собеседования на мой взгляд были заданы для того, чтобы выяснить, понимате ли вы разницу между физическим и логическим уровнями.В таблице но одном и том же поле построено абсолютно два одинаковых индекса, один из которых создан как Unique Constraint, а другой как Unique Index.

В чём смысл наличия обоих индексов - вот мой вопрос.
Даже SSMS не рассматривает Unique Constraint как собственно Constraint.

И кстати, не надо меня макать. Эти "Вопросы на собеседовании" я сам придумал. Если вы знаете и хотите помочь, помогите.

Александр52SandalTree, зачем вы задаете на собеседовании вопросы, на которые сами не можете ответить?Беседую с вами. Тут тоже не все могут на эти вопросы ответить.

GlorySandalTreeВ таблице но одном и том же поле построено абсолютно два одинаковых индекса, один из которых создан как Unique Constraint, а другой как Unique Index.
И в третий раз - Primary/Unique Constraint автоматически выполнятет create index. Всегда.
Сам по себе Constraint выполняет только декларативную роль.
Т.е. нет никаких двух индексов. Если только вы не создали явно еще индексы. Которые вы можете создавать всегда и которые не будут иметь к Constraint никакого отношения.

Я вам и скрипт привёл и картинку показал что в "msdb.dbo.log_shipping_primary_databases" два одинаковых индекса, а вы мне пытаетесь доказать что их нет.

Давайте быть конструктивными.
1. Создание Unique Constraint автоматически выполнятет create index
2. Дополнительный уникальный нефильтрованый индекс по тому-же полю будет попросту игнорироваться и лишь замедлять работу на инсертах.

Поправьте меня если я не прав.

Гость333SandalTreeВ таблице но одном и том же поле построено абсолютно два одинаковых индекса, один из которых создан как Unique Constraint, а другой как Unique Index.
Unique Constraint был создан без указания имени, наверняка в DDL таблицы после имени столбца просто приписали UNIQUE.
Для создания индекса написали отдельную DDL-инструкцию, не посмотрев, что уже есть Unique Constraint.
Мелкий баг, не более.

Спасибо. Я не был уверен, поэтому и поинтересовался.

GlorySandalTreeЯ вам и скрипт привёл и картинку показал что в "msdb.dbo.log_shipping_primary_databases" два одинаковых индекса, а вы мне пытаетесь доказать что их нет.
Вы привели картинку, где один кострайнт создал два индекса ?
Покажите мне код, где один кострайнт создал два индексаГлоря, вы это сами придумали и сами с собой спорите.

Гость333 уже подтвердил что я нашёл баг. И ничего особенного в этом нет.

Если вы считаете что это не баг, то тогда расскажите как система будет использовать индекс "uc1lsprimary_databases".

o-oа у меня вот есть подозрение, кто автор повторного индекса с картинки.
это тот, кто спросил "где констрейнт?", не найдя его в папочке контрейнтов.
наверное потому что не читал, что папка для CHECK CONSTRAINTS.
а юники надо в ключах искать, они же по сути ключи и есть.
просто всего один из них можно выбрать как PRIMARYНу это как-бы неожиданно от создателей MSDB.
При том что это никто с версии 2008 его не заметил и не пофиксил.

Поэтому у меня и возник резонный вопрос: "А вдруг это зачем-то нужно?"

o-oSandalTreeпропущено...
Спасибо. Я не был уверен, поэтому и поинтересовался.

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

В AdventureWorks такое меня не смутило, а вот в MSDB совсем другое дело.

У меня-то и записей в той таблице нет

GloryГость333Думаю, это можно назвать performance bug. Из-за дублирующего уникального индекса имеем ничем не оправданное замедление DML-операций.
Проанализируйте sys.dm_db_index_usage_stats своей базы. Наверное там тоже найдутся кандидаты на "performance bug". Даже недблированные.Глоря, но мы тебя всё равно уважаем.