Неправильно ли использовать ключевое слово USE в SQL Server?

Question

В настоящее время существует дискуссия (или, скорее, горячий аргумент) по поводу ключевого слова USE в верхней части сценария SQL Server.

Один из наших разработчиков сказал, что хорошо известно, что использование ключевого слова USE - это плохая практика. Его аргумент заключается в том, что если разработчик использует правильный логин, тогда это должно автоматически указывать соответствующую базу данных, а ключевое слово USE поощряет неправильное использование учетной записи SA. На нашем сайте его озабоченность подтверждается тем фактом, что в прошлом происходило злоупотребление SA, хотя предпринимаются шаги по устранению этой проблемы.

Другие разработчики утверждают, что из-за характера нашей работы (мы довольно часто работаем над несколькими базами данных за один день, иногда переключая задачи в очень короткие сроки), имея ключевое слово USE, полезно для удобства чтения в качестве напоминания о том, какая база данных мы работаем над и предотвращаем случайное использование SP в неправильной базе данных.

После обширного поиска в Интернете я могу найти только примеры, демонстрирующие его использование, и не могу найти никаких обсуждений в контексте «хорошей практики». Хотя поиск затруднен тем фактом, что USE - очень распространенное слово!

Каковы стандарты для этого? Является ли ключевое слово USE действительно плохой практикой или это хорошо, когда он был резервным?

Буду признателен за любые вводные данные - заблаговременно!

Answer 1

Я работаю с SQL Server около 13 лет и являюсь администратором базы данных более 20 лет, и за все это время я никогда не слышал аргументов против квалификации базы данных, которую вы будете использовать в начале скрипта , Я никогда не слышал об этом, но я думаю, что это больше, потому что это такая основная вещь.

Прежде всего, общая практика заключается в том, что только администраторы баз данных должны иметь доступ к учетной записи SA, и они не должны ее использовать. Ни один разработчик не должен иметь полномочия sysadmin, а администраторы баз данных должны иметь sysadmin для своих учетных записей AD или иметь отдельные учетные записи SQL Server, чтобы они могли быть подотчетны. SA слишком универсальна и должна использоваться только для чрезвычайных ситуаций (и тех поставщиков, которые настаивают на том, что они не могут жить без нее, но не заставляйте меня начинать с них). Стандартом во многих магазинах является отключение и/или переименование учетной записи SA. Так что забота о вашей проблеме злоупотребления SA.

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

В-третьих, я просматриваю много сценариев в своем текущем положении, и я просмотрел больше в других позициях. Одна из самых усугубляющих вещей, с которыми мне приходилось иметь дело, - это не знать, какая база данных (или сервер, если на то пошло), сценарий должен работать против. Итак, да, ПОЖАЛУЙСТА, положите USE в начало своего скрипта. И если вам нужно изменить базы данных наполовину вниз, поставьте там еще один USE-оператор. Если вы действительно ненавидите использование USE, тогда вы должны поместить три имени части, чтобы база данных была квалифицирована. В частности, поскольку DBA, который работает со всеми базами данных (некоторые из моих серверов имеют 100, а я видел серверы с 1000-ю базами данных), я сохраняю базу данных по умолчанию как master.

Answer 2

Аргумент не в том, правильно ли кодировать ключевое слово USE в верхней части скриптов - что приемлемо, рекомендуется & хорошая практика при внесении изменений в базу данных.

Чтобы быть более явным, допустимо или даже необходимо закодировать ключевое слово USE в верхней части ЗАПОМНЕННЫХ ПРОЦЕДУР, а не использовать логин для базы данных, который установит для вас базу данных по умолчанию, и в этом случае хранимая процедура всегда будет скомпилирован в правильную базу данных (вместо мастера). Кроме того, используя логин для базы данных, вы имеете только права действовать в контексте этой базы данных, это обеспечивает более строгую защиту/разрешения. & снижает риск того, что разработчики будут применять обновления к таблицам в неправильной базе данных.

Я ценю представление, которое DBA имеет в первом ответе, но у них есть другая перспектива для разработчиков, поэтому было бы интересно услышать другие мнения об этом от разработчиков & DBAs.

Answer 3

Если вы используете специальные сценарии DDL в общей среде, то вы действительно спрашиваете: «Каковы наилучшие методы для развертывания неуправляемого кода?», И ответ «Не делайте этого». Добавление директив USE просто решает одну проблему (она заставляет ваш контекст), создавая другую (она заставляет ваш контекст). Вы просто создаете дополнительные зависимости, которые очень трудно отслеживать и управлять.

Решение проблемы: разработчики теряют понимание контекста. Безмолвно изменив их контекст, они не станут их информировать.

Я бы сначала попросил запретить вход в систему sa, и я бы стал спорить. Далее, я бы поспорил для изменения базы данных по умолчанию для всех, особенно sa, в пустую базу данных. Это устраняет большую часть потенциального ущерба, и если вы удалите все разрешения пользователя из этой базы данных, вы также незамедлительно обратитесь к разработчику, который забывает переключиться. Если вы действительно хотите повеселиться, создайте триггер DDL, который отправит команду электронной почте, если кто-то запускает скрипт по умолчанию db.