Por que o prefixo do esquema (dbo) é obrigatório quando chamamos uma função?

Quando o usuário é mapeado com o esquema padrão (dbo) e podemos selecionar todas as tabelas em [dbo] sem prefixar o esquema.

Podemos executar procedimentos armazenados sem prefixo, se estiver no esquema padrão.

Dado isso, por que precisamos prefixar uma função com o esquema?

Obrigado!

sql-server functions

— Rajesh Ranjan
fonte

Respostas:

Então, por que podemos chamar a função sem prefixo (esquema), criado no dbo?

Do documento online de livros sobre UDF

Funções com valor escalar podem ser chamadas onde expressões escalares são usadas. Isso inclui colunas computadas e definições de restrição CHECK. Funções com valor escalar também podem ser executadas usando a instrução EXECUTE. Funções com valor escalar devem ser chamadas usando pelo menos o nome de duas partes da função .

Portanto, essa é basicamente uma restrição definida pela equipe de desenvolvimento do SQL Server e considero bastante correta. Mesmo que de alguma forma seja permitido (apenas por uma questão de conversa) eu ainda usaria o prefixo Schema.

Eu sempre apoio o uso do nome do esquema, mesmo que funcionasse sem adicioná-lo. Essa é uma prática recomendada e todos os desenvolvedores "Boas" a usam, independentemente de sua redundância.

A outra razão que vejo é que o mecanismo de banco de dados precisa de algo para diferenciar entre funções do sistema getdate ()e funções definidas pelo usuário. Se você puder chamar a função sem o nome do esquema, como o mecanismo de banco de dados diferenciaria entre a função criada pelo usuário denominada Getdate ou a função GETDATE () do sistema.

— Shanky
fonte

Então, por que é diferente com os SPs. Como você disse, pode ser para evitar colisões de nomes. Acabei de criar um SP "create procedure sp_help as select getdate ()" no meu banco de dados de usuários e quando executo com ou sem o esquema (dbo), o SQL Server se refere ao sistema SP. Por que ele não executa o meu SP que eu criei.

— Rajesh Ranjan

@rajeshRajan Como você tem sp_procname (você prefixou seu procedimento com SP), isso força o SQL Server a procurar primeiro no banco de dados mestre o plano compilado e, como esse proc existe no banco de dados mestre, ele não será executado, caso contrário, no mestre, então ele teria executado o seu. Você nunca deve criar proc com o prefixo sp_, pois há problemas de desempenho.

— Shanky

Acho que Shanky respondeu diretamente à pergunta "por que" quando mencionou que foi definida pela equipe de desenvolvimento do SQL Server. Você pode perguntar por que eles fizeram isso e por que o comportamento das funções é inconsistente com os procedimentos, mas a resposta provavelmente não importa muito.

— Michael J Swart

BTW, o impacto no desempenho dos procedimentos que começam com "sp_" não pode ser medido. Não tem sido um problema há anos. O prefixo sp ainda pode não ser uma boa ideia, mas o desempenho não é o motivo.

— Michael J Swart

A outra resposta explica que essa é uma restrição, mas não a razão.

O requisito nem sempre é verdadeiro. UDFs escalares podem ser EXECeditados e ainda usar resolução implícita ( exemplo )

Eu imagino que isso é para evitar colisões de nomes.

Se fosse permitido referenciar funções sem esquema, alguém que criou sua própria função que passou a ser chamado crypt_gen_random em 2000 ou 2005 encontraria problemas ao atualizar para uma versão posterior, pois esse se tornou o nome de uma função incorporada em 2008.

Não há ambiguidade com o execuso, pois as funções incorporadas não podem ser chamadas assim.

— Martin Smith
fonte

— Rajesh Ranjan

@Rajesh. Os objetos iniciados por sp_ são especiais para procurar sempre no banco de dados mestre / recurso. E está documentado que esse prefixo deve ser evitado. Não existe tal convenção para funções internas.

— Martin Smith