När du ska använda procedurer

Det finns ett antal fördelar med att använda procedurer, allt baserat på att sql-instruktioner flyttas från programmet till datakällan med hjälp av procedurer. Det som finns kvar i programmet är ett driftskompatibelt proceduranrop. Dessa fördelar är:

• Prestanda Procedurer är vanligtvis det snabbaste sättet att köra SQL-instruktioner. Precis som förberedd körning kompileras och körs uttrycket i två separata steg. Till skillnad från förberedd körning, utförs procedurer endast vid körning. De kompileras vid en annan tidpunkt.

• Affärsregler En affärsregel är en regel om hur ett företag gör affärer. Till exempel kan endast någon med rubriken Säljare kunna lägga till nya försäljningsorder. Genom att placera dessa regler i procedurer kan enskilda företag anpassa vertikala program genom att skriva om de procedurer som anropas av programmet utan att behöva ändra programkoden. Ett orderpostprogram kan till exempel anropa proceduren InsertOrder med ett fast antal parametrar. exakt hur InsertOrder implementeras kan variera från företag till företag.

• Utbytbarhet Nära relaterat till att placera affärsregler i procedurer är att procedurer kan ersättas utan att behöva kompilera om applikationen. Om en affärsregel ändras efter att ett företag har köpt och installerat ett program kan företaget ändra proceduren som innehåller den regeln. Från programmets synvinkel har ingenting ändrats; det kallar fortfarande en viss procedur för att utföra en viss uppgift.

• DBMS-specifik SQL Procedurer är ett sätt för program att utnyttja DBMS-specifika SQL och fortfarande vara driftskompatibla. En procedur på en DBMS som har stöd för flödeskontrollinstruktioner i SQL kan till exempel fånga upp och återställa från fel, medan en procedur på en DBMS som inte stöder flödeskontrollinstruktioner helt enkelt kan returnera ett fel.

• Procedurer överlever transaktioner I vissa datakällor tas åtkomstplanerna för alla förberedda instruktioner för en anslutning bort när en transaktion genomförs eller återgår. Genom att placera SQL-instruktioner i procedurer, som lagras permanent i datakällan, överlever uttrycken transaktionen. Om procedurerna överlever i ett förberett, delvis förberett eller oförberett tillstånd är DBMS-specifikt.

• Separat utveckling Procedurer kan utvecklas separat från resten av programmet. I stora företag kan detta ge ett sätt att ytterligare utnyttja kompetensen hos högspecialiserade programmerare. Med andra ord kan programprogram programmerare skriva kod för användargränssnittet och databasprogram programmerare kan skriva procedurer.

Procedurer används vanligtvis av vertikala och anpassade program. Dessa program brukar utföra fasta uppgifter och det är möjligt att hårdkoda proceduranrop i dem. Ett orderinmatningsprogram kan till exempel anropa procedurerna InsertOrder, DeleteOrder, UpdateOrder och GetOrders.

Det finns ingen anledning att anropa procedurer från generiska program. Procedurer skrivs vanligtvis för att utföra en uppgift i samband med ett visst program och har därför ingen användning för generiska program. Ett kalkylblad har till exempel ingen anledning att anropa den InsertOrder-procedur som just nämnts. Dessutom bör generiska program inte skapa procedurer vid körning i hopp om snabbare körning av instruktioner. Detta är inte bara sannolikt långsammare än förberedd eller direkt körning, det kräver även DBMS-specifika SQL-instruktioner.

Ett undantag till detta är programutvecklingsmiljöer, som ofta är ett sätt för programmerare att skapa SQL-instruktioner som kör procedurer och kan vara ett sätt för programmerare att testa procedurer. Sådana miljöer anropar SQLProcedures för att lista tillgängliga procedurer och SQLProcedureColumns för att visa parametrarna input, input/output och output, procedurens returvärde och kolumnerna i eventuella resultatuppsättningar som skapats av en procedur. Sådana förfaranden måste dock utarbetas i förväg för varje datakälla. Detta kräver DBMS-specifika SQL-instruktioner.

Det finns tre stora nackdelar med att använda procedurer. Den första är att procedurerna måste skrivas och kompileras för varje DBMS som programmet ska köras med. Detta är inte ett problem för anpassade program, men det kan avsevärt öka utvecklings- och underhållstiden för vertikala program som är utformade för att köras med ett antal DBMS.

Den andra nackdelen är att många DBMS inte stöder procedurer. Återigen är detta troligtvis ett problem för vertikala program som är utformade för att köras med ett antal DBMS. För att avgöra om procedurer stöds anropar ett program SQLGetInfo med alternativet SQL_PROCEDURES.

Den tredje nackdelen, som är särskilt tillämplig på programutvecklingsmiljöer, är att ODBC inte definierar en standard grammatik för att skapa procedurer. Det vill säga, även om program kan anropa procedurer interoperabelt, kan de inte skapa dem interoperabelt.