Funzione vs. stored procedure in SQL Server

Ho imparato funzioni e stored procedure per un bel po 'ma non so perché e quando dovrei usare una funzione o una procedura memorizzata. Mi sembrano uguali, forse perché sono un po 'alle prime armi.

Qualcuno può dirmi perché?

Le funzioni sono valori calcolati e non possono apportare modifiche ambientali permanenti a SQL Server(ovvero, nessuna INSERTo UPDATEaffermazione consentita).

Una funzione può essere utilizzata in linea nelle SQListruzioni se restituisce un valore scalare o può essere unita se restituisce un set di risultati.

Un punto degno di nota dai commenti, che riassumono la risposta. Grazie a @Sean K Anderson:

Le funzioni seguono la definizione di informatica in quanto DEVONO restituire un valore e non possono alterare i dati che ricevono come parametri (gli argomenti). Le funzioni non possono modificare nulla, devono avere almeno un parametro e devono restituire un valore. I proc memorizzati non devono avere un parametro, possono cambiare gli oggetti del database e non devono restituire un valore.

Come chiamare la SQLfunzione dalla procedura di archiviazione e quando utilizziamo una funzione anziché la procedura memorizzata.

Ciao amici, oggi discuteremo quando utilizzare la stored procedure e quando utilizzare la funzione. In team semplice Se si desidera calcolare alcuni valori, verrà restituito un singolo valore, quindi non è richiesto:

https://programmingtechtutorial.blogspot.com/2020/01/when-use-storeprocedure-and-when-use.html

La differenza tra SP e UDF è elencata di seguito:

+---------------------------------+----------------------------------------+
| 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.    |                                        |
+---------------------------------+----------------------------------------+

Le funzioni e le stored procedure hanno scopi separati. Sebbene non sia la migliore analogia, le funzioni possono essere viste letteralmente come qualsiasi altra funzione che useresti in qualsiasi linguaggio di programmazione, ma i proc memorizzati sono più simili a singoli programmi o uno script batch.

Le funzioni normalmente hanno un output e opzionalmente input. L'output può quindi essere utilizzato come input per un'altra funzione (un SQL Server integrato come DATEDIFF, LEN, ecc.) O come predicato di una query SQL, ad esempio SELECT a, b, dbo.MyFunction(c) FROM tableoppure SELECT a, b, c FROM table WHERE a = dbo.MyFunc(c).

I proc memorizzati vengono utilizzati per associare query SQL in una transazione e interfacciarsi con il mondo esterno. Frame come ADO.NET, ecc. Non possono chiamare direttamente una funzione, ma possono chiamare direttamente un proc memorizzato.

Le funzioni presentano tuttavia un pericolo nascosto: possono essere utilizzate in modo improprio e causare problemi di prestazioni piuttosto sgradevoli: considerare questa query:

SELECT * FROM dbo.MyTable WHERE col1 = dbo.MyFunction(col2)

Dove MyFunction è dichiarato come:

CREATE FUNCTION MyFunction (@someValue INTEGER) RETURNS INTEGER
AS
BEGIN
   DECLARE @retval INTEGER

   SELECT localValue 
      FROM dbo.localToNationalMapTable
      WHERE nationalValue = @someValue

   RETURN @retval
END

Quello che succede qui è che la funzione MyFunction viene chiamata per ogni riga nella tabella MyTable. Se MyTable ha 1000 righe, allora ci sono altre 1000 query ad hoc sul database. Allo stesso modo, se la funzione viene chiamata quando specificato nelle specifiche della colonna, la funzione verrà chiamata per ogni riga restituita da SELECT.

Quindi devi essere attento alle funzioni di scrittura. Se selezioni SELECT da una tabella in una funzione, devi chiederti se può essere eseguito meglio con un JOIN nel proc memorizzato principale o in qualche altro costrutto SQL (come CASE ... WHEN ... ELSE ... FINE).

Differenze tra procedure memorizzate e funzioni definite dall'utente:

• Le stored procedure non possono essere utilizzate nelle istruzioni Select.
• Le procedure memorizzate supportano la risoluzione dei nomi posticipata.
• Le procedure memorizzate vengono generalmente utilizzate per eseguire la logica aziendale.
• Le stored procedure possono restituire qualsiasi tipo di dati.
• Le procedure memorizzate possono accettare un numero maggiore di parametri di input rispetto alle funzioni definite dall'utente. Le procedure memorizzate possono avere fino a 21.000 parametri di input.
• Le procedure memorizzate possono eseguire Dynamic SQL.
• Le procedure memorizzate supportano la gestione degli errori.
• Le funzioni non deterministiche possono essere utilizzate nelle stored procedure.

• Le funzioni definite dall'utente possono essere utilizzate nelle istruzioni Select.
• Le funzioni definite dall'utente non supportano la risoluzione dei nomi differiti.
• Le funzioni definite dall'utente vengono generalmente utilizzate per i calcoli.
• Le funzioni definite dall'utente dovrebbero restituire un valore.
• Le funzioni definite dall'utente non possono restituire immagini.
• Le funzioni definite dall'utente accettano un numero inferiore di parametri di input rispetto alle procedure memorizzate. Gli UDF possono avere fino a 1.023 parametri di input.
• Le tabelle temporanee non possono essere utilizzate nelle funzioni definite dall'utente.
• Le funzioni definite dall'utente non possono eseguire Dynamic SQL.
• Le funzioni definite dall'utente non supportano la gestione degli errori. RAISEERRORO @@ERRORnon sono ammessi negli UDF.
• Le funzioni non deterministiche non possono essere utilizzate negli UDF. Ad esempio, GETDATE()non può essere utilizzato negli UDF.

Scrivere una funzione definita dall'utente quando si desidera calcolare e restituire un valore da utilizzare in altre istruzioni SQL; scrivere una procedura memorizzata quando si desidera invece è di raggruppare un insieme forse complesso di istruzioni SQL. Questi sono due casi d'uso piuttosto diversi, dopo tutto!

              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.

Differenza di base

La funzione deve restituire un valore ma in Stored procedure è facoltativa (la procedura può restituire zero o n valori).

Le funzioni possono avere solo parametri di input, mentre le procedure possono avere parametri di input / output.

La funzione accetta un parametro di input è obbligatoria ma la Stored Procedure può richiedere da o a n parametri di input.

Le funzioni possono essere richiamate dalla procedura mentre le procedure non possono essere richiamate dalla funzione.

Differenza anticipata

La procedura consente l'istruzione SELECT e DML (INSERT / UPDATE / DELETE) in essa, mentre la funzione consente solo l'istruzione SELECT in essa.

Le procedure non possono essere utilizzate in un'istruzione SELECT mentre la funzione può essere incorporata in un'istruzione SELECT.

Le stored procedure non possono essere utilizzate nelle istruzioni SQL in nessun punto della sezione WHERE / HAVING / SELECT, mentre la funzione può essere.

Le funzioni che restituiscono tabelle possono essere trattate come un altro set di righe. Questo può essere usato in JOIN con altre tabelle.

La funzione incorporata può essere considerata come vista che accetta parametri e può essere utilizzata in JOIN e altre operazioni di Rowset.

L'eccezione può essere gestita dal blocco try-catch in una procedura mentre il blocco try-catch non può essere utilizzato in una funzione.

Possiamo andare per la gestione delle transazioni in procedura mentre non possiamo andare in funzione.

fonte

una funzione definita dall'utente è uno strumento importante disponibile per un programmatore di server sql. È possibile utilizzarlo in linea in un'istruzione SQL in questo modo

SELECT a, lookupValue(b), c FROM customers 

dove lookupValuesarà un UDF. Questo tipo di funzionalità non è possibile quando si utilizza una procedura memorizzata. Allo stesso tempo, non è possibile eseguire determinate operazioni all'interno di un UDF. La cosa fondamentale da ricordare qui è che UDF:

• impossibile creare cambiamenti permanenti
• non è possibile modificare i dati

una procedura memorizzata può fare queste cose.

Per me l'uso in linea di un UDF è l'uso più importante di un UDF.

Le Stored procedure sono utilizzate come script . Eseguono una serie di comandi per te e puoi programmarli per l'esecuzione in determinati momenti. Di solito esegue istruzioni DML multiple come INSERT, UPDATE, DELETE, ecc. O addirittura SELECT.

Le funzioni sono usate come metodi. Gli passi qualcosa e restituisce un risultato. Dovrebbe essere piccolo e veloce - lo fa al volo. Solitamente utilizzato in un'istruzione SELECT.

Procedura memorizzata:

• È come un programma in miniatura in SQL Server.
• Può essere semplice come un'istruzione select o complesso come uno script lungo che aggiunge, elimina, aggiorna e / o legge dati da più tabelle in un database.
• (Può implementare loop e cursori, che consentono entrambi di lavorare con risultati più piccoli o operazioni riga per riga sui dati.)
• Dovrebbe essere chiamato usando EXECo EXECUTEistruzione.
• Restituisce le variabili della tabella, ma non possiamo usare il OUTparametro.
• Supporta transazioni.

Funzione:

• Non può essere utilizzato per aggiornare, eliminare o aggiungere record al database.
• Restituisce semplicemente un singolo valore o un valore di tabella.

• Può essere utilizzato solo per selezionare i record. Tuttavia, può essere chiamato molto facilmente dall'interno di SQL standard, come ad esempio:

  SELECT dbo.functionname('Parameter1')

  o

  SELECT Name, dbo.Functionname('Parameter1') FROM sysObjects

• Per semplici operazioni di selezione riutilizzabili, le funzioni possono semplificare il codice. Diffida solo dall'uso delle JOINclausole nelle tue funzioni. Se la tua funzione ha una JOINclausola e la chiami da un'altra istruzione select che restituisce più risultati, quella funzione chiamerà JOIN quelle tabelle insieme per ogni linea restituita nel set di risultati. Quindi, sebbene possano essere utili per semplificare un po 'di logica, possono anche essere un collo di bottiglia delle prestazioni se non vengono utilizzati correttamente.

• Restituisce i valori utilizzando il OUTparametro
• Non supporta le transazioni.

Funzione definita dall'utente.

1. La funzione deve restituire un valore.
2. Consentirà solo le istruzioni Select, non ci consentirà di utilizzare le istruzioni DML.
3. Consentirà solo i parametri di input, non supporta i parametri di output.
4. Non ci consentirà di utilizzare i blocchi try-catch.
5. Le transazioni non sono consentite all'interno delle funzioni.
6. Possiamo usare solo variabili di tabella, non consentirà l'utilizzo di tabelle temporanee.
7. Le stored procedure non possono essere richiamate da una funzione.
8. Le funzioni possono essere chiamate da un'istruzione select.
9. Un UDF può essere utilizzato nella clausola join come set di risultati.

Stored procedure

1. La Stored procedure può restituire o meno valori.
2. Può avere istruzioni selezionate e istruzioni DML come inserire, aggiornare, eliminare e così via
3. Può avere sia parametri di input che di output.
4. Per la gestione delle eccezioni possiamo usare try catch blocks.
5. Può utilizzare le transazioni all'interno di Stored procedure.
6. Può utilizzare sia le variabili di tabella sia le tabelle temporanee in essa contenute.
7. Le Stored procedure possono chiamare funzioni.
8. Le procedure non possono essere richiamate dalle istruzioni Select / Where / Being e così via. L'istruzione Execute / Exec può essere utilizzata per chiamare / eseguire Stored Procedure.
9. Le procedure non possono essere utilizzate nella clausola Join

Per decidere quando utilizzare quali potrebbero essere utili i seguenti punti:

1. Le procedure memorizzate non possono restituire una variabile di tabella in cui come funzione può farlo.

2. È possibile utilizzare le procedure memorizzate per modificare i parametri dell'ambiente server in cui non è possibile utilizzare le funzioni.

Saluti

Le funzioni di SQL Server, come i cursori, sono pensate per essere utilizzate come ultima arma! Hanno problemi di prestazioni e quindi l'uso di una funzione con valori di tabella dovrebbe essere evitato il più possibile. Parlare di prestazioni è parlare di una tabella con oltre 1.000.000 di record ospitati su un server su un hardware di classe media; in caso contrario, non è necessario preoccuparsi dell'hit di performance causato dalle funzioni.

1. Non utilizzare mai una funzione per restituire un set di risultati a un codice esterno (come ADO.Net)
2. Utilizzare il più possibile la combinazione di visualizzazioni / proc memorizzate. puoi recuperare da futuri problemi di crescita delle prestazioni utilizzando i suggerimenti che DTA (Database Tuning Adviser) ti darebbe (come visualizzazioni indicizzate e statistiche) - a volte!

per ulteriori riferimenti consultare: http://database.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html

Inizia con funzioni che restituiscono un singolo valore. La cosa bella è che puoi inserire il codice usato di frequente in una funzione e restituirlo come colonna in un set di risultati.

Quindi, è possibile utilizzare una funzione per un elenco di città con parametri. dbo.GetCitiesIn ("NY") Restituisce una tabella che può essere utilizzata come join.

È un modo di organizzare il codice. Sapere quando qualcosa è riutilizzabile e quando è una perdita di tempo è qualcosa che si ottiene solo attraverso prove, errori ed esperienze.

Inoltre, le funzioni sono una buona idea in SQL Server. Sono più veloci e possono essere abbastanza potenti. Selezioni in linea e dirette. Attento a non abusare.

Ecco un motivo pratico per preferire le funzioni alle procedure memorizzate. Se si dispone di una procedura memorizzata che richiede i risultati di un'altra procedura memorizzata, è necessario utilizzare un'istruzione insert-exec. Ciò significa che è necessario creare una tabella temporanea e utilizzare execun'istruzione per inserire i risultati della procedura memorizzata nella tabella temporanea. È disordinato. Un problema con questo è che insert-execs non può essere nidificato .

Se sei bloccato con le procedure memorizzate che chiamano altre stored procedure, potresti imbatterti in questo. Se la stored procedure nidificata restituisce semplicemente un set di dati, può essere sostituita con una funzione con valori di tabella e non verrà più visualizzato questo errore.

( questo è un altro motivo per cui dovremmo tenere la logica di business fuori dal database )

• È obbligatorio che Function restituisca un valore mentre non è per la stored procedure.
• Selezionare le istruzioni accettate solo in UDF mentre le istruzioni DML non sono necessarie.
• La procedura memorizzata accetta qualsiasi istruzione e istruzione DML.
• UDF consente solo ingressi e non uscite.
• La procedura memorizzata consente sia ingressi che uscite.
• I blocchi di cattura non possono essere utilizzati in UDF ma possono essere utilizzati nella stored procedure.
• Non sono consentite transazioni nelle funzioni in UDF ma nelle stored procedure sono consentite.
• Solo le variabili di tabella possono essere utilizzate in UDF e non le tabelle temporanee.
• La procedura memorizzata consente sia le variabili di tabella sia le tabelle temporanee.
• UDF non consente di richiamare le procedure memorizzate dalle funzioni mentre le procedure memorizzate consentono la chiamata delle funzioni.
• UDF viene utilizzato nella clausola join mentre le stored procedure non possono essere utilizzate nella clausola join.
• La procedura memorizzata consentirà sempre di tornare a zero. L'UDF, al contrario, ha valori che devono ritornare a un punto predeterminato.

• Le funzioni possono essere utilizzate in un'istruzione select in cui non è possibile eseguire le procedure.

• La procedura memorizzata accetta sia i parametri di input che di output, ma Functions accetta solo i parametri di input.

• Le funzioni non possono restituire valori di tipo text, ntext, image & timestamps dove possibile.

• Le funzioni possono essere utilizzate come tipi di dati definiti dall'utente nella tabella di creazione, ma le procedure no.

*** Ad esempio: -create table <tablename>(name varchar(10),salary getsal(name))

Qui getsal è una funzione definita dall'utente che restituisce un tipo di stipendio, quando viene creata una tabella non viene assegnata alcuna memoria per il tipo di stipendio e anche la funzione getal non viene eseguita, ma quando stiamo recuperando alcuni valori da questa tabella, la funzione getal viene eseguita e il return Type viene restituito come set di risultati.

Mi rendo conto che questa è una domanda molto antica, ma non vedo un aspetto cruciale menzionato in nessuna delle risposte: l'inserimento nel piano di query.

Le funzioni possono essere ...

1. Scalare:

   CREATE FUNCTION ... RETURNS scalar_type AS BEGIN ... END

2. Tabella a più istruzioni valutata:

   CREATE FUNCTION ... RETURNS @r TABLE(...) AS BEGIN ... END

3. Tabella in linea valutata:

   CREATE FUNCTION ... RETURNS TABLE AS RETURN SELECT ...

Il terzo tipo (inline con valori di tabella) viene trattato da Query Optimizer essenzialmente come viste (parametrizzate), il che significa che fare riferimento alla funzione dalla query è simile a incollare il corpo SQL della funzione (senza effettivamente incollare la copia), portando ai seguenti vantaggi:

• Il pianificatore di query può ottimizzare l'esecuzione della funzione inline proprio come farebbe con qualsiasi altra sottoquery (ad es. Eliminare le colonne non utilizzate, spingere i predicati verso il basso, selezionare diverse strategie JOIN ecc.).
• La combinazione di diverse funzioni incorporate non richiede di materializzare il risultato dal primo prima di inviarlo al successivo.

Quanto sopra può portare a risparmi sulle prestazioni potenzialmente significativi, specialmente quando si combinano più livelli di funzioni.

NOTA: sembra che SQL Server 2019 introdurrà anche una qualche forma di allineamento delle funzioni scalari .

In SQL Server, funzioni e stored procedure sono due diversi tipi di entità.

Funzione: nel database di SQL Server, le funzioni vengono utilizzate per eseguire alcune azioni e l'azione restituisce immediatamente un risultato. Le funzioni sono di due tipi:

1. Sistema definito

2. Definito dall'utente

Stored procedure: in SQL Server, le stored procedure sono archiviate nel server e possono restituire zero, valori singoli e multipli. Le Stored procedure sono di due tipi:

1. Procedure memorizzate dal sistema
2. Procedure definite dall'utente