2 svar · 222 visningar · startad av Vide
Eftersom en Stored Procedure kompileras tycker man att det borde finnas en vinst ur prestandasynpunkt att inte ha koden i t.ex ASP eller COM.
Men hur stor är den egenligen, hur mycket påverkas det av inparametrar?
Finns det egentligen någon mening i att lägga vanliga (Select, Insert, Update & Delete) SQL-satser i en SP, eller tappar man bara skalbaraheten i grundkoden?
Om man utvecklar i .net är det väll bara att börja vänja sig vid att använda det. Med tanke på nästa generations sqlserver. Personligen tycker jag det är rätt klumpigt då man tex byter tex från mssql till mysql och måste ändra om de lager som anropar ens sp:ar.
Läste en artikel om prestandavinsten med sp och den var inte så superstor men den fanns iaf, ska rota reda på länken.
Den längsta sp jag skrivit var på ca 20 tättskrivna A4-sidor. Har för mig att det skiljde en faktor 5-10 mellan första gången den kördes (okompilerad) och andra gången (kompilerad). Den returnerade dessutom nästan inget.
Sen slipper man dessutom nätverksoverheaden genom att bara skicka ett funktionsnamn snarare än hela SQL-texten.
Almänna tankar:
Stor kodmängd och liten resultatmängd - Stor vinst
Liten kodmängd och stor resultatmängd - Mindre vinst
