RE: TechEd Developer - Non siamo gli unici... :-D

In riferimento ai post precedenti #1 e #2.

Non voglio innescare una polemica, ma ritengo che BISOGNA usare le stored procedures, sia per ragioni di sicurezza ma anche per ragioni prestazionali. E' vero però che in alcuni casi le SPs sono molto controproducenti, ad esempio quando si vuole fare una form di ricerca che includa o escluda criteri di filtro. In questo caso infatti la struttura della query non è rigida ma dinamica e allora tanto vale usare statement sql specifici.

Ho scritto una piccola store in SQL 2005 nel database Northwind:

CREATE PROCEDURE [dbo].[GetOrdersByDate]( @StartDate datetime, @EndDate datetime) AS DECLARE @Number int SELECT @Number=COUNT(*) FROM Orders WHERE OrderDate>=@StartDate AND OrderDate<=@EndDate GO

e questo statement di prova, nel quale eseguo 10000 volte la chiamata alla SP e 10000 volte la chiamata ad un analogo statement sql. Ogni chiamata ha parametri diversi.

DECLARE @StartDate datetime DECLARE @EndDate datetime DECLARE @Time datetime DECLARE @i int DECLARE @Query VARCHAR(1000) SET @Time = GETDATE() SET @i = 0 SELECT @StartDate = '2000-01-01' SELECT @EndDate = '2010-01-01' WHILE (@i<10000) BEGIN -- Questo calcolo è inutile qui: serve per avere lo stesso contesto della -- chiamata via sql statement SET @Query ='DECLARE @Number int SELECT @Number=COUNT(*) FROM Orders WHERE OrderDate>=''' + CONVERT(VARCHAR(4), YEAR(@StartDate)) + '-' + CONVERT(VARCHAR(2), MONTH(@StartDate)) + '-' + CONVERT(VARCHAR(2), DAY(@StartDate)) + ''' AND OrderDate<=''' + + CONVERT(VARCHAR(4), YEAR(@EndDate)) + '-' + CONVERT(VARCHAR(2), MONTH(@EndDate)) + '-' + CONVERT(VARCHAR(2), DAY(@EndDate)) + '''' EXECUTE [Northwind].[dbo].[GetOrdersByDate] @StartDate ,@EndDate SET @StartDate = DATEADD(day, 1, @StartDate) SET @i = @i + 1 END SELECT 'Store procedure:' + CAST(DATEDIFF(ms,@Time,GETDATE()) AS VARCHAR(50)) SET @Time = GETDATE() SET @i = 0 SELECT @StartDate = '2000-01-01' SELECT @EndDate = '2010-01-01' WHILE (@i<10000) BEGIN SET @Query ='DECLARE @Number int SELECT @Number=COUNT(*) FROM Orders WHERE OrderDate>=''' + CONVERT(VARCHAR(4), YEAR(@StartDate)) + '-' + CONVERT(VARCHAR(2), MONTH(@StartDate)) + '-' + CONVERT(VARCHAR(2), DAY(@StartDate)) + ''' AND OrderDate<=''' + + CONVERT(VARCHAR(4), YEAR(@EndDate)) + '-' + CONVERT(VARCHAR(2), MONTH(@EndDate)) + '-' + CONVERT(VARCHAR(2), DAY(@EndDate)) + '''' EXECUTE (@Query) SET @StartDate = DATEADD(day, 1, @StartDate) SET @i = @i + 1 END SELECT 'Query:' + CAST(DATEDIFF(ms,@Time,GETDATE()) AS VARCHAR(50))

Risultato: 10000 chiamate a SP in ~560 ms, 10000 chiamate a sql statement in ~16300 ms. Quindi in questo semplice esempio le SP sono ~29 volte più veloci degli statement sql. Quindi, la scelta di cosa usare dipende ancora una volta dal particolare contesto.

posted @ Friday, November 10, 2006 12:49 PM

Print

Comments on this entry:

# re: RE: TechEd Developer - Non siamo gli unici... :-D

Left by Raffaele Rialdi at 11/10/2006 1:58 PM
Gravatar
Non voglio aprire guerre di religione sul discorso. Ma in quanto alla compilazione e alla preparazione dei parametri, è sufficiente usare i command con i parameter per avere risultati analoghi.
È chiaro che se la stored deve ciclarsi un cursore e fare un lavoro in locale sarà più prestazionale in quanto non c'è marshaling in e out dal processo di sql.
Ma il discorso a cui si riferisce Ingo Rammer è relativo al processo di retrieve e update dei dati in una applicazione enterprise. Non posso certamente creare 100 stored procedure per ciascuna entity. Se cambia solo una proprietà sono più efficente con una query dinamica che tocca solo una colonna.

Comunque a ciascuno le sue valutazioni. È indubbio che il discorso di Ingo Rammer che viene da una esperienza riconosciuta sul campo è più che valido nella maggior parte di applicazioni che vediamo sul campo tutti i giorni.
È ovvio che poi ci sono casi specifici in cui questo non è vero, ma sono i casi meno comuni.

Personalmente non sono un taleano delle non-stored, ma sono sempre stato contro ad una presa di posizione delle stored a tutti i costi.

# re: RE: TechEd Developer - Non siamo gli unici... :-D

Left by Cristian Bressan at 11/10/2006 3:30 PM
Gravatar
"Non posso certamente creare 100 stored procedure per ciascuna entity." si riferisce ad un problema di manutenzione e rapidità di sviluppo dell'applicazione. Invece "Usare le stored procedure per avere performance è un errore." e "Non usate le stored procedure" significa non usate le sp se non per ragioni di sicurezza e questo a mio avviso non è corretto. Ci sono prodotti della stessa Microsoft, il CRM ad esempio, che usano quasi esclusivamente sp.
Il caso di aggiornamento con lock ottimistico sul singolo campo è il caso più eclatante di svantaggio nell'uso di sp. In caso di retrieve però, non vedo grosse controindicazioni nell'uso di sp.
Ripeto cmq, la scelta di cosa usare dipende ancora una volta dal particolare contesto. Sono contro ad una presa di posizione dei sql statement a tutti i costi.
Il prestigio e la competenza di Ingo Rammer non sono messi in discussione, solo che le sue considerazioni vanno contestualizzate, come d'altronde hai fatto rispondendo al mio post.
P.S.: "è sufficiente usare i command con i parameter per avere risultati analoghi. " è vero in parte (l'esempio è volutamente provocatorio): le sp sono sempre più veloci, in quanto le query parametrizzate pur essendo cachate hanno ulteriori controlli di sicurezza.
Cmq io depongo l'ascia perchè già tanto si è discusso in merito, solo che la frase "Non usate le stored procedure" mi sembrava un pò troppo forte.
In realtà è solo invidia xchè siete al TechEd. ;)

# re: RE: TechEd Developer - Non siamo gli unici... :-D

Left by Raffaele Rialdi at 11/11/2006 11:19 AM
Gravatar
LOL ... :-)
Solo per dovere di cronaca e non per polemica devo dire che il test che hai pubblicato compara pere con mele. Se lanci dei command da ado.net con i parameters ottieni una cosa che è sostanzialmente uguale a quella che ottieni con le stored procedure, con il vantaggio di poter creare quello statement dinamicamente. Allo stesso tempo però se la chiami mille volte con parametri differenti avrà i vantaggi della compilazione, dell'execution plan, etc. così come hanno le sp. Per la sicurezza è sufficiente che la connessione sia aperta per il ciclo da mille e l'overhead restante è veramente minimo.

Per quanto riguarda il contesto, posso assicurarti che l'affermazione di Ingo Rammer l'abbiamo virgolettata e non era all'interno di una frase più estesa.
Quello che lasciava intendere è ovviamente che bisogna comparare tecnologie per l'uso che se ne può effettivamente fare. Cioè se per aggiorarnare una entity con 10 proprietà devo creare una 1023 stored procedure per gestire tutte le possibili permutazioni di aggioranamento delle 10 proprietà, ecco fatto che le sp non sono la tecnologia giusta da usare.

Con tutto ciò ci sono tanti casi in cui fare a meno delle sp è penalizzante. Pensiamo all'aumento di un listino del 10%. Ciclo il cursore server e faccio tutto in evidentemente meno tempo perché non ho il marshalling dovuto al passaggio di dati fuori dal processo di sql server (o altro db).

In sostanza anch'io sotterro l'ascia e mi auguro che un po' tutti facciano uso delle tecnologie dopo aver pensato e non per partito preso.

# re: RE: TechEd Developer - Non siamo gli unici... :-D

Left by kimi at 1/3/2008 11:13 AM
Gravatar
bressan

# re: RE: TechEd Developer - Non siamo gli unici... :-D

Left by sohbet at 2/8/2009 2:00 PM
Gravatar

# 美女野兽交友网

Left by 美女野兽交友网 at 6/8/2010 10:35 AM
Gravatar
美女野兽交友网是一个专为单身白领打造的开心网规模大。
安全纯净的婚恋交友平台开心网通过它您可以与朋友。
开心网在线游戏及积分兑换礼品等各项服务。

# re: RE: TechEd Developer - Non siamo gli unici... :-D

Left by seks gif at 4/27/2017 4:39 PM
Gravatar
Comments have been closed on this topic.
«August»
SunMonTueWedThuFriSat
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567