Почему префикс схемы (dbo) является обязательным, когда мы вызываем функцию?


9

Когда пользователь сопоставлен со схемой по умолчанию (dbo), и мы можем выбрать все таблицы в [dbo] без добавления префикса схемы.

Мы можем выполнять хранимые процедуры без префикса, если он находится в схеме по умолчанию.

Учитывая это, зачем нам префикс функции со схемой?

Спасибо!

Ответы:


11

Тогда почему мы можем вызывать функцию без префикса (схемы), созданную под dbo?

Из Книги Онлайн Документ на UDF

Скалярные функции могут быть вызваны там, где используются скалярные выражения. Это включает в себя вычисляемые столбцы и определения ограничений CHECK. Скалярные функции также можно выполнить с помощью оператора EXECUTE. Скалярные функции должны вызываться с использованием как минимум двухкомпонентного имени функции .

Так что это в основном ограничение, установленное командой разработчиков SQL Server, и я считаю его вполне правильным. Даже если это как-то разрешено (просто для разговора), я бы все равно использовал префикс Schema.

Я всегда поддерживаю использование имени схемы, даже если оно будет работать без его добавления. Это лучшая практика, и все «хорошие» разработчики используют ее независимо от того, насколько она избыточна.

Другая причина, по которой я вижу, состоит в том, что ядру СУБД нужно что-то различать между системными функциями getdate ()и пользовательскими функциями. Если вам разрешено вызывать функцию без имени схемы, как ядро ​​базы данных будет различать созданную пользователем функцию с именем Getdate или системную функцию GETDATE ().


Тогда почему это отличается от SP. Как вы сказали, это может быть, чтобы избежать именования коллизий. Я только что создал SP «создать процедуру sp_help as select getdate ()» в своей базе данных пользователей, и когда я выполняю со схемой (dbo) или без нее, SQL Server ссылается на системный SP. Почему он не выполняет мой SP, который я создал.
Раджеш Ранджан

1
@rajeshRajan Так как у вас есть sp_procname (вы поставили свою процедуру перед SP), это заставляет SQL Server сначала искать в базе данных master скомпилированный план, и поскольку этот процесс существует в базе данных master, он будет выполнен не вашим, если он не был найден. в мастере тогда он бы казнил тебя. Вы никогда не должны создавать proc с префиксом sp_, потому что у него есть проблемы с производительностью.
Шэнки

Я думаю, что Шанки ответил на вопрос «почему» непосредственно, когда он упомянул, что он был задан командой разработчиков SQL Server. Вы можете спросить, почему они это сделали и почему поведение функций несовместимо с процедурами, но ответ, вероятно, не имеет большого значения.
Майкл Дж Сварт

1
Кстати, влияние на производительность процедур, которые начинаются с "sp_", не может быть измерено. Это не было проблемой в течение многих лет. Префикс sp все еще может не быть хорошей идеей, но производительность не является причиной.
Майкл Дж Сварт

10

Другой ответ объясняет, что это ограничение, но не причина, почему.

Требование не всегда верно. Скалярные UDF могут быть EXEC-ed и все еще использовать неявное разрешение ( пример )

Я предполагаю, что это чтобы избежать именования коллизий.

Если бы к функциям было разрешено ссылаться без схемы, то кто-то, создавший свою собственную функцию, которая была вызвана crypt_gen_randomв 2000 или 2005 году, столкнулся бы с проблемами при обновлении до более поздней версии, поскольку это стало названием встроенной функции в 2008 году.

Нет никакой двусмысленности с execиспользованием, поскольку встроенные функции не могут быть вызваны таким образом.


Тогда почему это отличается от SP. Как вы сказали, это может быть, чтобы избежать именования коллизий. Я только что создал SP «создать процедуру sp_help as select getdate ()» в своей пользовательской базе данных, и когда я выполняю со схемой (dbo) или без нее, SQL Server ссылается на системный SP. Почему он не выполняет мой SP, который я создал.
Раджеш Ранджан

3
@Rajesh. Объекты, начинающиеся с sp_, имеют специальный корпус, чтобы всегда искать в базе данных master / resource. И задокументировано, что этого префикса следует избегать. Для встроенных функций такого соглашения нет.
Мартин Смит
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.