listtoview,
Смысл имеет. Когда имя объекта заранее известно, с ним проще выполнять нужные действия. Ну там, переименовать, отключить / удалить, свойства изменить.
Пример из личной практики: допустим у вас есть система, которая установлена у ваших клиентов, причем хостится все не в облаке вашими силами, а on premises у них. Вы выпускаете новую версию, в которой нужно, ну скажем, добавить еще одно поле в существующий ключ.
Если имя констрейнта известно и одинаково у всех клиентов, то в change script, который новая версия приложения будет прогонять на клиентской базе при ее апгрейде, можно будет напрямую написать что-то типа (за синтаксис не ручаюсь, но для примера сойдет):
1.
2.
3.
4.
alter table dbo.Records drop constraint [UQ_Records_CreateDate];
go
alter table dbo.Records add constraint [UQ_Records_CreateDate_SomeFieldId] unique (CreateDate, SomeFieldId);
go
Если же уникальный ключ был создан безымянным, то сначала придется попариться и найти
именно его имя в метаданных (что в некоторых случаях может быть крайне нетривиальной задачей), после чего выполнять приведенный выше код в динамическом SQL.
Я в свое время написал скрипт, который генерит вызовы sp_rename для переименования всех таких объектов, которые не соответствуют принятому соглашению. Перед сборкой релиза прогоняю скрипт на БД, потом из Visual Studio делаю Schema Compare с проектом базы, подтягиваю изменения в проект и готово. Проще, чем каждый раз руками все это набивать.
