Om man skal bruge Stored Procedures eller ej, er mere en religiøs eller politisk diskussion på en bar end ikke.
Det, der skal gøres, er klart at definere dine ansøgningslag og ikke træde over disse grænser. Lagrede procedurer har flere fordele og ulemper i forhold til at udføre forespørgsler uden for databasen.
Fordel 1:Lagrede procedurer er modulære. Dette er en god ting fra et vedligeholdelsessynspunkt. Når der opstår forespørgselsproblemer i din ansøgning, vil du sandsynligvis være enig i, at det er meget nemmere at fejlfinde en lagret procedure end en indlejret forespørgsel, der er begravet i mange linjer med GUI-kode.
Fordel 2:Lagrede procedurer kan indstilles. Ved at have procedurer, der håndterer databasearbejdet for din grænseflade, eliminerer du behovet for at ændre GUI-kildekoden for at forbedre en forespørgsels ydeevne. Ændringer kan foretages i de lagrede procedurer - med hensyn til joinmetoder, forskellige tabeller osv. - som er gennemsigtige for frontend-grænsefladen.
Fordel 3:Lagrede procedurer abstraherer eller adskiller funktioner på serversiden fra klientsiden. Det er meget nemmere at kode en GUI-applikation til at kalde en procedure end at bygge en forespørgsel gennem GUI-koden.
Fordel 4:Lagrede procedurer er normalt skrevet af databaseudviklere/administratorer. Personer, der har disse roller, er normalt mere erfarne i at skrive effektive forespørgsler og SQL-sætninger. Dette frigør GUI-applikationsudviklere til at bruge deres færdigheder på de funktionelle og grafiske præsentationsdele af applikationen. Hvis du får dine folk til at udføre de opgaver, som de er bedst egnede til, så vil du i sidste ende producere en bedre samlet ansøgning.
Med alt dette i tankerne er der flere ulemper.
Ulempe 1:Applikationer, der involverer omfattende forretningslogik og -behandling, kunne belaste serveren for meget, hvis logikken udelukkende blev implementeret i lagrede procedurer. Eksempler på denne type behandling omfatter dataoverførsler, datagennemgange, datatransformationer og intensive beregningsoperationer. Du bør flytte denne type behandling til forretningsproces- eller dataadgangslogikkomponenter, som er en mere skalerbar ressource end din databaseserver.
Ulempe 2:Læg ikke hele din forretningslogik ind i lagrede procedurer. Vedligeholdelse og smidigheden af din applikation bliver et problem, når du skal ændre forretningslogikken i Sp-sproget. For eksempel skulle ISV-applikationer, der understøtter flere RDBMS, ikke skulle have separate lagrede procedurer for hvert system.
Ulempe 3:At skrive og vedligeholde lagrede procedurer er oftest et specialiseret færdighedssæt, som ikke alle udviklere besidder. Denne situation kan introducere flaskehalse i projektudviklingsplanen.
Jeg har nok savnet nogle fordele og ulemper, kommenter gerne.