Aprendi Funções e Procedimento Armazenado por um bom tempo, mas não sei por que e quando devo usar uma função ou um procedimento armazenado. Eles parecem iguais para mim, talvez porque eu seja meio novato nisso.
Alguém pode me dizer o porquê?
Aprendi Funções e Procedimento Armazenado por um bom tempo, mas não sei por que e quando devo usar uma função ou um procedimento armazenado. Eles parecem iguais para mim, talvez porque eu seja meio novato nisso.
Alguém pode me dizer o porquê?
Respostas:
Funções são valores calculados e não podem executar alterações ambientais permanentes em SQL Server
(isto é, nenhuma INSERT
ou UPDATE
declarações permitidas).
Uma função pode ser usada em linha nas SQL
instruções se retornar um valor escalar ou pode ser associada se retornar um conjunto de resultados.
Um ponto digno de nota nos comentários, que resumem a resposta. Graças a @Sean K Anderson:
As funções seguem a definição de ciência da computação, na medida em que DEVEM retornar um valor e não podem alterar os dados que recebem como parâmetros (os argumentos). As funções não têm permissão para alterar nada, devem ter pelo menos um parâmetro e devem retornar um valor. Os procs armazenados não precisam ter um parâmetro, podem alterar objetos do banco de dados e não precisam retornar um valor.
Como chamar a SQL
função do procedimento de armazenamento e quando usamos uma função em vez do procedimento armazenado.
Olá amigos, hoje discutiremos Quando usar o procedimento armazenado e quando usar a função. Em equipe simples Se você deseja calcular alguns valores e ele retornará um único valor, portanto, não é necessário:
https://programmingtechtutorial.blogspot.com/2020/01/when-use-storeprocedure-and-when-use.html
A diferença entre SP e UDF está listada abaixo:
+---------------------------------+----------------------------------------+
| Stored Procedure (SP) | Function (UDF - User Defined |
| | Function) |
+---------------------------------+----------------------------------------+
| SP can return zero , single or | Function must return a single value |
| multiple values. | (which may be a scalar or a table). |
+---------------------------------+----------------------------------------+
| We can use transaction in SP. | We can't use transaction in UDF. |
+---------------------------------+----------------------------------------+
| SP can have input/output | Only input parameter. |
| parameter. | |
+---------------------------------+----------------------------------------+
| We can call function from SP. | We can't call SP from function. |
+---------------------------------+----------------------------------------+
| We can't use SP in SELECT/ | We can use UDF in SELECT/ WHERE/ |
| WHERE/ HAVING statement. | HAVING statement. |
+---------------------------------+----------------------------------------+
| We can use exception handling | We can't use Try-Catch block in UDF. |
| using Try-Catch block in SP. | |
+---------------------------------+----------------------------------------+
Funções e procedimentos armazenados servem a propósitos separados. Embora não seja a melhor analogia, as funções podem ser vistas literalmente como qualquer outra função que você usaria em qualquer linguagem de programação, mas os procs armazenados são mais parecidos com programas individuais ou como um script em lote.
As funções normalmente têm uma saída e, opcionalmente, entradas. A saída pode ser usada como entrada para outra função (um SQL Server interno como DATEDIFF, LEN, etc) ou como predicado para uma Consulta SQL - por exemplo, SELECT a, b, dbo.MyFunction(c) FROM table
ou SELECT a, b, c FROM table WHERE a = dbo.MyFunc(c)
.
Os procs armazenados são usados para vincular consultas SQL em uma transação e fazer interface com o mundo externo. Estruturas como ADO.NET etc. não podem chamar uma função diretamente, mas podem chamar um proc armazenado diretamente.
Porém, as funções têm um perigo oculto: podem ser mal utilizadas e causar problemas de desempenho bastante desagradáveis: considere esta consulta:
SELECT * FROM dbo.MyTable WHERE col1 = dbo.MyFunction(col2)
Onde MyFunction é declarado como:
CREATE FUNCTION MyFunction (@someValue INTEGER) RETURNS INTEGER
AS
BEGIN
DECLARE @retval INTEGER
SELECT localValue
FROM dbo.localToNationalMapTable
WHERE nationalValue = @someValue
RETURN @retval
END
O que acontece aqui é que a função MyFunction é chamada para todas as linhas da tabela MyTable. Se MyTable tiver 1000 linhas, isso significa mais 1000 consultas ad-hoc no banco de dados. Da mesma forma, se a função for chamada quando especificada na especificação da coluna, a função será chamada para cada linha retornada pelo SELECT.
Então você precisa ter cuidado com as funções de escrita. Se você SELECT de uma tabela em uma função, precisa se perguntar se ela pode ser melhor executada com uma JOIN no processo armazenado pai ou em alguma outra construção SQL (como CASE ... WHEN ... ELSE ... FIM).
SELECT * from dbo.MyTableValuedFunction()
. Os Sprocs, por outro lado, podem ser chamados diretamente com o ADO.NET, configurando SqlCommand.CommandType
para CommandType.StoredProcedure
.
Diferenças entre procedimentos armazenados e funções definidas pelo usuário:
RAISEERROR
OU @@ERROR
não são permitidos em UDFs.GETDATE()
não pode ser usado em UDFs.GETDATE()
pode ser usado em uma função. O pivô do Não-determinístico não é bom.
Escreva uma função definida pelo usuário quando desejar calcular e retornar um valor para uso em outras instruções SQL; escreva um procedimento armazenado quando desejar, em vez disso, agrupe um conjunto possivelmente complexo de instruções SQL. Esses são dois casos de uso bem diferentes, afinal!
STORE PROCEDURE FUNCTION (USER DEFINED FUNCTION)
* Procedure can return 0, single or | * Function can return only single value
multiple values. |
|
* Procedure can have input, output | * Function can have only input
parameters. | parameters.
|
* Procedure cannot be called from | * Functions can be called from
function. | procedure.
|
* Procedure allows select as well as | * Function allows only select statement
DML statement in it. | in it.
|
* Exception can be handled by | * Try-catch block cannot be used in a
try-catch block in a procedure. | function.
|
* We can go for transaction management| * We can't go for transaction
in procedure. | management in function.
|
* Procedure cannot be utilized in a | * Function can be embedded in a select
select statement | statement.
|
* Procedure can affect the state | * Function can not affect the state
of database means it can perform | of database means it can not
CRUD operation on database. | perform CRUD operation on
| database.
|
* Procedure can use temporary tables. | * Function can not use
| temporary tables.
|
* Procedure can alter the server | * Function can not alter the
environment parameters. | environment parameters.
|
* Procedure can use when we want | * Function can use when we want
instead is to group a possibly- | to compute and return a value
complex set of SQL statements. | for use in other SQL
| statements.
Diferença básica
A função deve retornar um valor, mas no Procedimento Armazenado é opcional (o Procedimento pode retornar valores zero ou n).
As funções podem ter apenas parâmetros de entrada, enquanto os Procedimentos podem ter parâmetros de entrada / saída.
A função aceita um parâmetro de entrada e é obrigatória, mas o Stored Procedure pode levar até n parâmetros de entrada.
As funções podem ser chamadas a partir de Procedimento, enquanto os Procedimentos não podem ser chamados a partir de Função.
Diferença Avançada
O procedimento permite a instrução SELECT e DML (INSERT / UPDATE / DELETE), enquanto a Function permite apenas a instrução SELECT.
Os procedimentos não podem ser utilizados em uma instrução SELECT, enquanto a Function pode ser incorporada em uma instrução SELECT.
Os procedimentos armazenados não podem ser usados nas instruções SQL em qualquer lugar da seção WHERE / HAVING / SELECT, enquanto Function pode ser.
As funções que retornam tabelas podem ser tratadas como outro conjunto de linhas. Isso pode ser usado em JOINs com outras tabelas.
A função embutida pode ser vista como tendo parâmetros e pode ser usada em JOINs e outras operações de conjunto de linhas.
A exceção pode ser manipulada pelo bloco try-catch em um Procedimento, enquanto o bloco try-catch não pode ser usado em uma Função.
Podemos ir para o Gerenciamento de Transações no Procedimento, enquanto não podemos ir na Função.
Returns
palavra - chave e deve ser do tipo Escalar ou Tabela) , mas os procedimentos armazenados podem opcionalmente retornar: a) 1 Int
tipo de código de resultado por meio da Return
instrução e / ou b) 1+ parâmetros (incluindo o Cursor
tipo) por meio da Output
palavra - chave e / ou c) 1+ conjuntos de linhas por meio de Select
instruções.Se apenas 1 conjunto de linhas for retornado, ele pode ser usado como o argumento "execute_statement" de uma instrução "Insert Into".
uma função definida pelo usuário é uma ferramenta importante disponível para um programador de servidor sql. Você pode usá-lo em linha em uma instrução SQL como essa
SELECT a, lookupValue(b), c FROM customers
onde lookupValue
será uma UDF. Esse tipo de funcionalidade não é possível ao usar um procedimento armazenado. Ao mesmo tempo, você não pode fazer certas coisas dentro de uma UDF. O básico a lembrar aqui é que as UDFs:
um procedimento armazenado pode fazer essas coisas.
Para mim, o uso embutido de um UDF é o uso mais importante de um UDF.
Procedimentos armazenados são usados como scripts . Eles executam uma série de comandos para você e você pode agendá-los para execução em determinados horários. Geralmente executa várias instruções DML como INSERT, UPDATE, DELETE etc. ou até SELECT.
Funções são usadas como métodos. Você passa algo e retorna um resultado. Deve ser pequeno e rápido - faz isso na hora. Geralmente usado em uma instrução SELECT.
Procedimento armazenado:
EXEC
ou EXECUTE
instruçãoOUT
parâmetroFunção:
Só pode ser usado para selecionar registros. No entanto, pode ser chamado com muita facilidade a partir do SQL padrão, como:
SELECT dbo.functionname('Parameter1')
ou
SELECT Name, dbo.Functionname('Parameter1') FROM sysObjects
Para operações de seleção reutilizáveis simples, as funções podem simplificar o código. Apenas tenha cuidado ao usar JOIN
cláusulas em suas funções. Se sua função tiver uma JOIN
cláusula e você a chamar de outra instrução select que retorne vários resultados, essa chamada de função fará JOIN
essas tabelas juntas para cada linha retornada no conjunto de resultados. Portanto, embora possam ser úteis para simplificar alguma lógica, também podem ser um gargalo de desempenho se não forem usados corretamente.
OUT
parâmetroFunção definida pelo usuário.
Procedimento armazenado
Para decidir quando usar o que os seguintes pontos podem ajudar:
Os procedimentos armazenados não podem retornar uma variável de tabela, onde a função pode fazer isso.
Você pode usar procedimentos armazenados para alterar os parâmetros do ambiente do servidor, utilizando funções que não podem.
Felicidades
As funções do SQL Server, como cursores, devem ser usadas como sua última arma! Eles têm problemas de desempenho e, portanto, o uso de uma função com valor de tabela deve ser evitado o máximo possível. Falar sobre desempenho é falar de uma tabela com mais de 1.000.000 de registros hospedados em um servidor em um hardware de classe média; caso contrário, você não precisa se preocupar com o desempenho causado pelas funções.
para obter mais referências, consulte: http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html
Comece com funções que retornam um único valor. O bom é que você pode colocar o código usado com frequência em uma função e retorná-lo como uma coluna em um conjunto de resultados.
Em seguida, você pode usar uma função para uma lista parametrizada de cidades. dbo.GetCitiesIn ("NY") Isso retorna uma tabela que pode ser usada como uma associação.
É uma maneira de organizar o código. Saber quando algo é reutilizável e quando é uma perda de tempo é algo que só se obtém por tentativa, erro e experiência.
Além disso, as funções são uma boa ideia no SQL Server. Eles são mais rápidos e podem ser bastante poderosos. Seleciona inline e direta. Cuidado para não usar demais.
Aqui está um motivo prático para preferir funções a procedimentos armazenados. Se você tiver um procedimento armazenado que precise dos resultados de outro procedimento armazenado, precisará usar uma instrução insert-exec. Isso significa que você precisa criar uma tabela temporária e usar uma exec
instrução para inserir os resultados do procedimento armazenado na tabela temporária. É bagunçado. Um problema com isso é que os executivos de inserção não podem ser aninhados .
Se você estiver preso a procedimentos armazenados que chamam outros procedimentos armazenados, você pode se deparar com isso. Se o procedimento armazenado aninhado simplesmente retornar um conjunto de dados, ele poderá ser substituído por uma função com valor de tabela e você não receberá mais esse erro.
( esse é outro motivo pelo qual devemos manter a lógica de negócios fora do banco de dados )
As funções podem ser usadas em uma instrução select onde os procedimentos não podem.
O procedimento armazenado usa os parâmetros de entrada e saída, mas o Functions usa apenas parâmetros de entrada.
As funções não podem retornar valores do tipo texto, ntexto, imagem e registros de data e hora, sempre que possível.
As funções podem ser usadas como tipos de dados definidos pelo usuário na tabela create, mas os procedimentos não.
*** Por exemplo: -criar table <tablename>(name varchar(10),salary getsal(name))
Aqui getsal é uma função definida pelo usuário que retorna um tipo de salário, quando a tabela é criada, nenhum armazenamento é alocado para o tipo de salário e a função getsal também não é executada. Mas, quando estamos buscando alguns valores dessa tabela, a função getsal é executada e o return Tipo é retornado como o conjunto de resultados.
Sei que essa é uma pergunta muito antiga, mas não vejo um aspecto crucial mencionado em nenhuma das respostas: entrar no plano de consulta.
Funções podem ser ...
Escalar:
CREATE FUNCTION ... RETURNS scalar_type AS BEGIN ... END
Multi-instrução com valor de tabela:
CREATE FUNCTION ... RETURNS @r TABLE(...) AS BEGIN ... END
Com valor de tabela em linha:
CREATE FUNCTION ... RETURNS TABLE AS RETURN SELECT ...
O terceiro tipo (com valor de tabela embutido) é tratado pelo otimizador de consulta essencialmente como visualizações (parametrizadas), o que significa que a referência à função da sua consulta é semelhante a copiar e colar o corpo SQL da função (sem realmente copiar e colar), levando aos seguintes benefícios:
O exposto acima pode levar a economias de desempenho potencialmente significativas, especialmente ao combinar vários níveis de funções.
NOTA: Parece que o SQL Server 2019 também apresentará alguma forma de função escalar .
No SQL Server, funções e procedimento armazenado são dois tipos diferentes de entidades.
Função: no banco de dados SQL Server, as funções são usadas para executar algumas ações e a ação retorna um resultado imediatamente. Funções são dois tipos:
Sistema definido
Usuário definido
Procedimentos armazenados: No SQL Server, os procedimentos armazenados são armazenados no servidor e podem retornar zero, valores únicos e múltiplos. Procedimentos armazenados são dois tipos: