[Stored Procedures] Redenen gebruik Stored Proc.

[Verwijderd]

Wat zijn nu de voordelen en nadelen van het gebruik van Stored Procedures boven het gebruik van SQL-code in je functielaag?

Momenteel heb ik:
Voordelen:
- Efficienter ivm optimalisatie query door DBMS
- Efficienter ivm minder netwerkverkeer (SQL-code hoeft immers niet via de lijn naar het DBMS verstuurd te worden)
- Beveiliging; er kunnen geen onverwachte querys uitgevoerd worden. Alles ligt vast in het DBMS.

Nadelen
- Overstap naar ander DBMS die stored procedures niet ondersteunen, niet mogelijk.

[Verwijderd]

Je update makkelijker 1 sp op 'n sql server dan dat je een X aantal clients voorziet van geupdate code.

[Verwijderd]

Op donderdag 06 juni 2002 11:59 schreef Yarvieh het volgende:
Je update makkelijker 1 sp op 'n sql server dan dat je een X aantal clients voorziet van geupdate code.

Maar als je gebruik maakt van bijvoorbeeld EJB's dan hoeft er ook maar op een plek onderhoud gepleegd te worden toch?

[TheDane]

nog een voordeel: code is al gecompileerd, dus die stap kan overgeslagen worden;

nadeel: (imho) minder onderhoudsvriendelijke code

[mbravenboer]

Deze punten vind ik eigenlijk niet zo sterk:

Efficienter ivm optimalisatie query door DBMS

Dit kan ook met een voorgecompileerde SQL statement, uiteraard geldt hierbij het voordeel alleen bij herhaald gebruik, maar een DBMS kan een SQL statement die voor is gecompileerd ook best bewaren en gebruiken voor meerdere clients.

Efficienter ivm minder netwerkverkeer (SQL-code hoeft immers niet via de lijn naar het DBMS verstuurd te worden)

Dit is denk ik wel een behoorlijk detail. De SQL statement is in vrijwel alle gevallen verwaarloosbaar tov het resultaat van een query die over het netwerk wordt verzonden. Sowieso is de SQL statement zelf ook nog eens ingepakt in een message aan de DBMS server. Deze overhead blijft behouden bij het gebruik van een stored procedure.

[Uiligheid]

Ja, dit heb ik wel eens eerder gehoord inderdaad.

In ieder geval,
onderhoudsvriendelijk is het juist wel. De opmerking dat je op al je clients de code zal moeten veranderen is natuurlijk een beetje ondoordacht.
In principe zul je sowieso zorgen voor een functiescheiding waarbij een (aantal) module(s) zullen zorgen voor de data afhandeling. Dus op de clients zul je sowieso niet de code hoeven te veranderen.

Op onderstaande link staan nog een aantal nadelen van sp's.. maar ik ben het persoonlijk niet eens met de auteur..

http://www.geocities.com/tablizer/moretop.htm

Werk zelf momenteel in acces, dus zit mijn eigen sp's te maken

[Uiligheid]

Ik lees het geheel nog eens na, en ik denk in eens:

"wat is het voordeel van sp's boven SQL in je functielaag?"

Hruhum.. ik neem toch zeker aan dat je het dan over een data laag hebben? Of zitten we lekker te code-by-formen ?

[raptorix]

Nog wat voordelen:

-Sprocs kunnen aparte User rechten hebben
-Sprocs kunnen makkelijker gedugt/geanalyseert worden
-Sprocs kunnen op vrij eenvoudige manier input/output parameters verwerken (ook handig voor security!)

[mbravenboer]

raptorix: Sprocs kunnen makkelijker gedugt/geanalyseert worden

Dat kan ook in omgevingen waarin SQL geintegreerd is in de taal en er controle wordt uitgevoerd tov een database schema.

Sprocs kunnen op vrij eenvoudige manier input/output parameters verwerken (ook handig voor security!)

Dat kan ook met voorgecompileerde SQL statements (PreparedStatement in Java).

[JamesTiberius]

Voordeel: gruwelijk veel sneller?

... ik had eens een functie die ik in asp had omgezet naar een stored procedure.

Uitvoertijd van 90 seconden naar 15 !!

[raptorix]

Op donderdag 06 juni 2002 12:21 schreef mbravenboer het volgende:

[..]

Dat kan ook in omgevingen waarin SQL geintegreerd is in de taal en er controle wordt uitgevoerd tov een database schema.
[..]

Dat kan ook met voorgecompileerde SQL statements (PreparedStatement in Java).

Klopt, maar een database weet wat de beste manier van optimaliseren is omdat er bij een sproc al een executie plan aanwezig is, denk niet dat java kan weten wat de DB het fijnst vind.

Daarnaast is de analyse van iets wat puur in de DB gebeurt een stuk makkelijker, omdat je nooit rekening hoeft te houden met randprocessen, weet niet of je wel eens met de profiler van Sqlserver hebt gewerkt, maar dan weet je precies wat ik bedoel.

[mbravenboer]

raptorix: Klopt, maar een database weet wat de beste manier van optimaliseren is omdat er bij een sproc al een executie plan aanwezig is, denk niet dat java kan weten wat de DB het fijnst vind.

Dat is juist het punt waar de voorgecompileerde SQL statement voor is: je geeft het DBMS een SQL statement, waar het DBMS een query plan van kan compileren tot aan het fysieke query plan toe. Dit plan kan elke keer opnieuw gebruikt worden als de voorgecompileerde SQL statement wordt gebruikt.

De statement bevat hiertoe variabelen, die voor elke invocatie aangegeven kunnen worden. Java hoeft geen zicht te hebben om wat het DBMS 'fijn' vindt omdat de PreparedStatement slechts een interface is tot de voorgecompileerde query.

[Verwijderd]

Toevoeging wat betreft voordelen:
Bij Stored Procedures kunnen alle functies van het DBMS gebruikt worden, bij een driver is het nog maar de vraag of alle functies ondersteund worden door de driver...

[Verwijderd]

Het heeft gewoon een hoop voordelen.

1 In de meeste gevallen sneller
2 Meerdere query's tegelijk of afhankelijk van een aktie
3 Je kan user management toepassen
4 Schrijf een SP class en je code is stuk overzichtelijker
5 SP is beter te analyseren dmv de query analyzer
6 Een keer een query aanpassen binnen een SP en alle pagina's die die SP aanroepen zijn aangepast, sit is overigens ook een nadeel

Nadeel:

tja, niet?
je kan niet zomaar een andere DB gaan gebruiken. Maar ja wie vind mysql een optie? En een andere DB gebruiken, ik vind SQL gewoon heerlijk proggen.