Att använda sig av lagrade procedurer i asp/vb
Förord
När man pratar om lagrade procedurer (stored procedures) kan det tyckas vara ett konstigt ord, har något med databaser att göra och man "kallar på dom" - men sen är det inte mycket mer. En lagrad procedur kan liknas med en helt vanlig sql-fråga som du skall köra antingen från Visual Basic, ASP eller något annat program. Att förstå varför man använder detta kan sammanfattas med några ord, det går snabbare - mycket snabbare.Innehåll
Det som egentligen händer är att din lagrade procedur är kompilerad, testad och verifierad vilket innebär att databasmotorn inte behöver utföra denna kontrollen en gång till. Det innebär även att du inte behöver skicka lika mycket textmassa till databasservern från din sida och även det gör att det går snabbare. Om man kör samma procedur på samma sida så ligger även detta cachat och därmed tjänar du ytterligare tid.
Det finns givetvis många fördelar men kanske det viktigaste jag tycker är att du kan lägga intelligensen i databasen och låta asp/vb bara hantera resultatet - ett script kan förvanskas för olika ändamål - men när den lagrade proceduren finns på databasen så spelar det ingen roll vilka program som kallar på informationen - det blir alltid samma resultat. Det är här nästa aspekt kommer in - är det fel i proceduren blir det fel överallt, rättar du i proceduren blir det således också rätt överallt.
Nog om detta, när jag skriver en lagrad procedur så testar jag det först i min SQL-editor * och ser att det fungerar korrekt och att jag får med de parametrar som jag vill skicka med. Vi kan börja med ett exempel att skriva en selectsats:
* Du får fram SQL-editorn genom att i SQL Enterprise Manager välja Tools|SQL Server Query Analyzer.
SQL-satsen ovan tar ut förnamn, efternamn - konkatinerar (slår ihop) och kallar fältet namn istället, ålder på användarid = 28 som även vill visa sitt visitkort för andra. Vi testkör och får fram ett record, nu är det dags att skapa den nya lagrade proceduren:
Nu har vi skapat proceduren, det är dags att definera de fält som vi vill skicka med denna lagrade procedur. I detta fall är det userid och userpublic:
Samt ersätta våra värden med det som skickas till den lagrade proceduren:
Nu är faktiskt den lagrade proceduren klar. Nu sparar vi den och använder oss återigen av vårt sql-fönster och testar att kalla på den genom att skriva:
sp_GetUserInfo 28, 1
Tryck F5 så körs din fråga. Resultatet blir att du får en post innehållande fältet Name och lngAge. Nu är det dags att skriva en liten ASP-rutin som kallar den och får tag i den returnerade posten.
När man ser på det, så verkar det ju inte vara någon skillnad från vår ursprungliga sql-fråga, men som jag påpekade tidigare, uttaget går mycket snabbare - det kan röra sig om flera hundra procents prestandaökning i vissa fall. Logiken ligger på databasen och i din programkod så krävs minimalt med information vilket i sin tur medför renare program, färre fel, mindre kod, säkrare data och att rätta - det gör man på ett enda ställe om det blir fel.
Ett litet tips: I din SQL-editor kan det tänkas att du har flera sql-satser och några lagrade procedurer. Markera den sql du vill köra och tryck F5 - då körs bara det som markerats och inget annat.
Var denna artikeln användbar?
Om du gör någon intressant som grund av detta material så skicka gärna det med ett mail eller bifoga en länk till mig så presenterar jag detta som ytterligare exempelfiler för kursen. Om detta innehållet är felaktigt eller du lärt dig fler finesser så skriv gärna en rad eller varför inte en egen kurs baserat på dina erfarenheter. Sänd gärna in dina tips till denna kurs.
/Pelle Johansson
Det finns givetvis många fördelar men kanske det viktigaste jag tycker är att du kan lägga intelligensen i databasen och låta asp/vb bara hantera resultatet - ett script kan förvanskas för olika ändamål - men när den lagrade proceduren finns på databasen så spelar det ingen roll vilka program som kallar på informationen - det blir alltid samma resultat. Det är här nästa aspekt kommer in - är det fel i proceduren blir det fel överallt, rättar du i proceduren blir det således också rätt överallt.
Nog om detta, när jag skriver en lagrad procedur så testar jag det först i min SQL-editor * och ser att det fungerar korrekt och att jag får med de parametrar som jag vill skicka med. Vi kan börja med ett exempel att skriva en selectsats:
* Du får fram SQL-editorn genom att i SQL Enterprise Manager välja Tools|SQL Server Query Analyzer.
Select strFirstName +' '+ strLastName as Name, lngAge
From tblUser
Where lngUserID = 28
And blnUserPublic = 1
SQL-satsen ovan tar ut förnamn, efternamn - konkatinerar (slår ihop) och kallar fältet namn istället, ålder på användarid = 28 som även vill visa sitt visitkort för andra. Vi testkör och får fram ett record, nu är det dags att skapa den nya lagrade proceduren:
CREATE PROCEDURE sp_GetUserInfo
AS
Select strFirstName +' '+ strLastName as Name, lngAge
From tblUser
Where lngUserID = 28
And blnUserPublic = 1
Nu har vi skapat proceduren, det är dags att definera de fält som vi vill skicka med denna lagrade procedur. I detta fall är det userid och userpublic:
CREATE PROCEDURE sp_GetUserInfo
@userid int,
@userpublic int
AS
Select strFirstName +' '+ strLastName as Name, lngAge
From tblUser
Where lngUserID = 28
And blnUserPublic = 1
Samt ersätta våra värden med det som skickas till den lagrade proceduren:
CREATE PROCEDURE sp_GetUserInfo
@userid int,
@userpublic int
AS
Select strFirstName +' '+ strLastName as Name, lngAge
From tblUser
Where lngUserID = @userid
And blnUserPublic = @userpublic
Nu är faktiskt den lagrade proceduren klar. Nu sparar vi den och använder oss återigen av vårt sql-fönster och testar att kalla på den genom att skriva:
sp_GetUserInfo 28, 1
Tryck F5 så körs din fråga. Resultatet blir att du får en post innehållande fältet Name och lngAge. Nu är det dags att skriva en liten ASP-rutin som kallar den och får tag i den returnerade posten.
<%
' ansluter till min datakälla
set con = server.createObject("ADODB.Connection")
con.open "mindsn","user,"password"
' vem skall vi presentera?
userid = Request("userid")
userpublic = Request("userpublic")
' kör vår lagrade procedur
set rst=con.execute("sp_GetUserInfo " & userid & "," & userpublic)
' fick vi någon post?
Response.Write "sp_GetUserInfo returnerade:
"
If Not (Rst.Eof Or Rst.Bof) Then
Response.Write Rst("name") & "-" & Rst("lngAge")
Else
Response.Write "ingen träff."
End If
' frigör objekten
set rst=nothing
set con=nothing
%>
När man ser på det, så verkar det ju inte vara någon skillnad från vår ursprungliga sql-fråga, men som jag påpekade tidigare, uttaget går mycket snabbare - det kan röra sig om flera hundra procents prestandaökning i vissa fall. Logiken ligger på databasen och i din programkod så krävs minimalt med information vilket i sin tur medför renare program, färre fel, mindre kod, säkrare data och att rätta - det gör man på ett enda ställe om det blir fel.
Ett litet tips: I din SQL-editor kan det tänkas att du har flera sql-satser och några lagrade procedurer. Markera den sql du vill köra och tryck F5 - då körs bara det som markerats och inget annat.
Var denna artikeln användbar?
Om du gör någon intressant som grund av detta material så skicka gärna det med ett mail eller bifoga en länk till mig så presenterar jag detta som ytterligare exempelfiler för kursen. Om detta innehållet är felaktigt eller du lärt dig fler finesser så skriv gärna en rad eller varför inte en egen kurs baserat på dina erfarenheter. Sänd gärna in dina tips till denna kurs.
/Pelle Johansson
0 Kommentarer