[ALG] zeg nee tegen Stored Procedures *

[Delphi32]

Verwijderd schreef op 01 september 2004 @ 14:52:
Sterker nog, moet je er bij het opzetten van een echt belangrijke database niet juist rekening mee houden dat deze in zijn levensduur door meerdere platforms geraadpleegd zal moeten gaan worden?

Je hebt een punt hier. Maar mijn vraag is dan wel: hoe weet jij dat de database die je NU ontwerpt voor een applicatie, straks door meerdere platforms geraadpleegd wordt ZONDER dat de oorspronkelijke code (inclusief BL laag) hergebruikt kan worden? Dit klinkt m.i. iets teveel naar "programming for the future". Ongetwijfeld kan je scenario's uit de kast trekken waaruit blijkt dat multi-platform geen hergebruik van bestaande BL-lagen met zich meebrengt, maar ik kan er tegenover zetten dat er ook scenario's denkbaar zijn waarin dit wel kan. Kern van dit punt: je weet niet wat de toekomst brengen zal. Waarom dan inflexibiliteit en complexiteit inbouwen waar dat nu niet nodig is? Zie ook mn volgende punt:

...er continue naar streeft om de hoeveelheid sp's zo minimaal en overzichtelijk mogelijk te houden door bijvoorbeeld:
...
- Zoveel mogelijk met "overloading" (= parameters met default waardes) te werken

Als er iets is waar ik als ontwikkelaar dus heel slecht mee uit de voeten kan, dan zijn het overloaded procedures en default parameter values. Imho zorgen die juist voor toename van het aantal procedures (dit is wel afhankelijk van de gebruikte taal), toename van het aantal mogelijk op te geven parameters (ik heb ooit een docent gehad die 5 parameters toch echt het maximum vond) en daarmee een verhoogde ondoorzichtigheid en onoverzichtelijkheid. Net wat je niet wilt dus.
Ik zou willen zeggen: bewijzen van de onwerkbaarheid van overloaded procedures en default parameter values liggen ter inzage, maar het project waar ik aan werk is helaas geen open source

[Verwijderd]

Delphi32 schreef op 02 september 2004 @ 00:07:
[...]
Je hebt een punt hier. Maar mijn vraag is dan wel: hoe weet jij dat de database die je NU ontwerpt voor een applicatie, straks door meerdere platforms geraadpleegd wordt ZONDER dat de oorspronkelijke code (inclusief BL laag) hergebruikt kan worden? Dit klinkt m.i. iets teveel naar "programming for the future".

Ik begrijp wat je bedoelt, wanneer is iets "programming for the future" en wanneer is iets een "best practice"? Platformheterogeniteit, abstractie en encapsulatie, betere integriteitsbeveiliging en "division of labor" (richting DBA) zijn in mijn ogen goede argumenten om sprocs te gebruiken. Aan de andere kant zie ik een POTENTIEEL onderhoudsprobleem (dat m.i. dus op een aantal manieren te bestrijden is, zie hierboven) als grootste nadeel, waarbij ik moet zeggen dat ik vind dat dit punt nog onvoldoende onderbouwd is omdat het alternatief, het verspreiden van allerlei SQL in een (al dan niet min of meer automatisch gegenereerde) DAL of -erger nog maar dan moeilijk te voorkomen- in de BLL of zelfs frontend, onderbelicht is gebleven.

Als er iets is waar ik als ontwikkelaar dus heel slecht mee uit de voeten kan, dan zijn het overloaded procedures en default parameter values. Imho zorgen die juist voor toename van het aantal procedures (dit is wel afhankelijk van de gebruikte taal)

Kun je een concreet voorbeeld geven waardoor het gebruik van overloads/defaults een wildgroei van het aantal sprocs veroorzaakt? Ik bedoel met het gebruiken van "overloads" bijvoorbeeld het combineren van UPDATE en INSERT sprocs in een. Afhankelijk van of (bijv.) een identity veld wordt meegegeven kun je bepalen wat moet worden uitgevoerd, bijv:

code:

  PROCEDURE Person_Save
    @id int = NULL,
    @name nvarchar(50)
  AS
    
     IF @id IS NULL BEGIN

         INSERT INTO.....

     END
     ELSE BEGIN

         UPDATE .....
     
     END
  GO

[EfBe]

Verwijderd schreef op 02 september 2004 @ 04:07:
Kun je een concreet voorbeeld geven waardoor het gebruik van overloads/defaults een wildgroei van het aantal sprocs veroorzaakt? Ik bedoel met het gebruiken van "overloads" bijvoorbeeld het combineren van UPDATE en INSERT sprocs in een. Afhankelijk van of (bijv.) een identity veld wordt meegegeven kun je bepalen wat moet worden uitgevoerd, bijv:

code:

  PROCEDURE Person_Save
    @id int = NULL,
    @name nvarchar(50)
  AS
    
     IF @id IS NULL BEGIN

         INSERT INTO.....

     END
     ELSE BEGIN

         UPDATE .....
     
     END
  GO

Dit performt voor geen meter. Elke execution zal de proc's execution plan opnieuw bepalen vanwege de IF. Dit soort logica hoort in je app thuis: DAAR roep je 2 routines aan, OF update, OF insert. Verder is het zo dat je bij dit soort routines dus in een update alle velden update. Bij rows waar een 1MB blob in zit en je een 4 byte integer wilt wijzigen is dat niet echt efficient

[Maasluip]

Bobco schreef op 31 augustus 2004 @ 20:10:
[...]

Voor grotere organisaties is dat helaas niet haalbaar. Vaak worden databases benaderd door meer dan 1 applicatie en dan vaak ook nog tegelijkertijd. In dat soort situaties is een developer absoluut niet in staat om de impact op de performance van de database in te schatten of te meten.

Daar ben ik het niet helemaal mee eens.

Om te beginnen ging het over trage queries, en als ontwikkelaar moet je voldoende kennis hebben om te kunnen herkennen (en zeker te testen in een statische omgeving!) of een query traag of snel is (simpele eerste criterium: ga je over indexen bij grote tabellen? En een fout die vaak gemaakt wordt is testen met slechts een fractie aan records als in de uiteindelijke situatie). Ik heb genoeg queries en stored procedures gezien dat ik me hoofdschuddend afvroeg welke amateur dit had gemaakt (lees: processtime van een SP van 5 minuten naar 5 seconden gebracht) of zelf de handdoek in de ring heb moeten gooien met de mededeling 'deze requirement is zonder extra indexen niet performant te maken'.
En een extra index aanleggen is natuurlijk ook niet iets wat je zonder nadenken wil doen.

Dat je in een dynamische situatie nog extra problemen kunt hebben is duidelijk, en met een heel (ervaren) projektteam hebben we moeten vaststellen dat locks van queries die op zich niet zo gek lang duren wel tot gevolg kunnen hebben dat de hele applicatie niet meer werkt, maar om nu te zeggen dat een ontwikkelaar zich daar niet van bewust hoeft te zijn vind ik een beetje kortzichtig. Oogkleppen op en ieder zijn eigen hokje lees ik dan, en daar ben ik geen voorstander van.

[Bobco]

Maasluip schreef op 02 september 2004 @ 09:24:
[...]
Daar ben ik het niet helemaal mee eens.

Om te beginnen ging het over trage queries, en als ontwikkelaar moet je voldoende kennis hebben om te kunnen herkennen (en zeker te testen in een statische omgeving!) of een query traag of snel is (simpele eerste criterium: ga je over indexen bij grote tabellen?
[..]
En een extra index aanleggen is natuurlijk ook niet iets wat je zonder nadenken wil doen.
[...]
Oogkleppen op en ieder zijn eigen hokje lees ik dan, en daar ben ik geen voorstander van.

Ik begrijp denk ik wel wat je bedoelt, maar meen standpunt is dat een ontwikkelaar van een applicatie soms niet voldoende zicht heeft op wat er met een database gebeurd in een produktiesituatie waar ook andere applicaties gebruik maken van dezelfde database.

Je noemt zelf het punt van het aanleggen van extra indexen. Een index, IMHO, is een hulpmiddel voor een RDBMS om snel bepaalde rows terug te kunnen vinden. Iedereen weet dat indexen geweldig zijn voor reads, maar minder leuk voor updates. Een extreem voorbeeld: applicatie A doet alleen maar reads, applicaties B t/m G doen alleen maar updates (inserts, deletes,...).

De ontwikkelaar van applicatie A wil natuurlijk overal en nergens indexen, de ontwikkelaars van de andere applicaties zijn daar op tegen. Hier is duidelijk sprake van een belangenconflict en dat moet opgelost worden door een andere partij: de DBA. Die moet kunnen zeggen of er met een bepaald technisch datamodel de gewenste performance gehaald kan worden voor ALLE applicaties.

Een database is voor mij niets anders dan een resource die beheerd wordt door een partij die daar verstand van heeft. Met een goede DBA kun je overleggen over databasestructuren, te verwachten responsetijden en meer van dat soort dingen. Dat is geen kwestie van oogkleppen op en in je hok blijven zitten maar van gespecialiseerde kennis. Je kunt als applicatieontwikkelaar niet goed alle ins en outs van een bepaald RDBMS bijhouden. Voor 'gewone' applicaties hoeft dat ook niet, maar op het moent dat je het laatste stukje performance uit een database wilt persen heb je die kennis wel nodig.

[EfBe]

Voor 'gewone' applicaties hoeft dat ook niet, maar op het moent dat je het laatste stukje performance uit een database wilt persen heb je die kennis wel nodig.

Dit is een totaal andere discussie. Als iedere cycle telt, zijn alle consessies geoorloofd, en gebruik je dus bv geen tier-ed model, maar prak je bv een datareader direct in de gui zodat deze sneller opbouwt.

Jouw situatie die je schetst met een database waar A alleen uit leest en B, C en D in schrijven, is wat Microsoft bv heeft onderzocht en wat als uitgangspunt is genomen voor Yukon: men is beter af in zo'n situatie waarbij men 2 databases gebruikt: 1 voor A en 1 voor B, C en D. Tenzij natuurlijk A direct moet kunnen lezen wat B, C en D schrijven. In dat geval heb je gewoon te leven met de limieten die dat oplevert.

Verder is de dicussie omtrent performance leuk, maar ondergeschikt. Zodra je consessies gaat doen om maar meer performance te halen, betaal je een prijs voor die consessies: minder onderhoudbaarheid en soms hogere complexiteit in je applicatie. Het lullige is dat men dat niet beseft. Men wil EN top performance EN top onderhoudbaarheid EN een erg lage complexiteit. En dat alles ook nog eens supergemakkelijk te realiseren. Echter hoe meer performance je wilt, hoe meer je aan gemak en onderhoudbaarheid moet inleveren.

Constante = performance * onderhoudbaarheid (waarbij performance en onderhoudbaarheid >=1)

Waarom normaliseert men een datamodel uit? voor leesacties (en voor schrijfacties ook) is het niet de snelste benadering. Zomaar een voorbeeld. Men gaat dan wel steevast roepen "Ja maar normaliseren is logisch, dat is correct", maar zo simpel ligt het niet: als elke cycle telt is ook elke consessie geoorloofd, immers performance is het enige doel.

Wil je dus performance, dan ben je klaar met deze discussie. Kom dan echter niet aan met een huilverhaal dat je na 2 jaar 2 dagen per week zit te vloeken omdat het systeem zo verschrikkelijk slecht inelkaar is gezet.

[Verwijderd]

EfBe schreef op 02 september 2004 @ 09:04:

Dit performt voor geen meter.

Dat valt reuze mee hoor, en zoals je zelf een kleine drie uurtjes later zegt:

EfBe schreef op 02 september 2004 @ 11:48:
Zodra je consessies gaat doen om maar meer performance te halen, betaal je een prijs voor die consessies: minder onderhoudbaarheid en soms hogere complexiteit in je applicatie.

[...]

Wil je dus performance, dan ben je klaar met deze discussie.

Begrijp me niet verkeerd, performance is belangrijk. Maar schaalbaarheid, beveiliging en onderhoudbaarheid zijn in de meeste scenarios belangrijker. Het stukje (pseudo) code is een voorbeeld van hoe je de hoeveelheid sprocs kunt verminderen, natuurlijk kun je met een voorbeeld komen waarin dit niet de optimale oplossing is (grote BLOBs) maar dat vind ik erg flauw en niet echt nuttig voor de discussie.

[whoami]

Ff kicken.
Ik kreeg net een mailtje van Red Gate met daarin een link naar dit artikel.

Douglas Reilly stelt hier de standpunten van Rob Howard en EfBe tegenover elkaar.
Er moet wel ff gemeld worden dat die Douglas Reilly zelf ook wel een beetje een SP - advocate is denk ik, en hij komt ook tot een conclusie waar ik het al langer mee eens was:
Stored Procedures moet je niet afzweren, en je moet ze ook niet altijd blind gebruiken. Gebruik SP's wanneer het aangewezen is, en gebruik ad-hoc queries wanneer deze aangewezen zijn. Het is gewoon een afweging die je moet maken.

[curry684]

Zodra je iemand ooit een compleet workflowsysteem in HTML hebt zien rondmailen vanuit stored procedures weet je weer waarom ze kut zijn. Je gaat huilen zodra je serieus 'SELECT '<html><body><h1>' + fieldname + '</h1>' etc. in een SP ziet opduiken.

Stored procedures zijn imho voor maintenance operaties, scheduled jobs en andere terugkerende acties die op z'n tijd al of niet handmatig uitgevoerd moeten worden. Voor applicatiedevelopment is het gewoon een crime in maintenance (altijd leuk als je een localhost, devserver, testserver en productieserver moet updaten met verschillend geversioneerde SP's) en zijn ze gewoon niet op hun plaats. Een database moet data opslaan, de DB-layer van de applicatie moet het beheren. En beheert dus de queries.

[curry684]

Even nog wat meer historische discussiepunten openbreken (ik heb deze discussie vorig jaar gemist obviously wegens 2 weken vakantie ):

DrFrankenstoner schreef op maandag 30 augustus 2004 @ 00:13:
[...]

Sterker nog, views moeten uberhaupt verboden worden (behalve inlined views dan in queries en materialized views voor datawarehousing)

En federated views in SQL Server Enterprise

Persoonlijk vind ik dat de database verantwoordelijk moet zijn voor het bewaken van de integriteit van je data. Dit betekend dus dat er logica in je database kan zitten. Dingen als een email adres valideren is absoluut applicatie laag werk. Dingen als sequences ophogen, foreign (check, unique) keys controleren is definitief database werk. Business rules zijn een discutabel punt. Er zijn gevallen waar je die in je applicatie wilt hebben en soms toch ook niet. Juist als je meerdere applicaties op dezelfde database plakt, is het verstandig om de business rules in de database te hangen naar mijn mening. App. 1 kan namelijk de dataset voor app. 2 vernaggelen, omdat er andere business rules schijnen te gelden. Gecentraliseerd werken dus.

Dat los je imho op met een 3-tier model, waarbij de applicaties tegen een service aanpraten die de data beheert en als enige ter wereld de database in kan.

[whoami]

curry684 schreef op donderdag 31 maart 2005 @ 16:23:


En federated views in SQL Server Enterprise

Nog nooit van gehoord....
Bedoel je niet 'indexed views' ?

[ Voor 9% gewijzigd door whoami op 31-03-2005 16:27 ]

[P_de_B]

whoami schreef op donderdag 31 maart 2005 @ 16:26:
[...]


Nog nooit van gehoord....
Bedoel je niet 'indexed views' ?

Ik durfde het al niet te vragen

Ik denk dat 'ie partitioned views bedoeld?

[curry684]

Uhm ja 'partitioned views' op 'federated servers', excuses Partitioned views zijn overigens per definitie federated, dus tis een beetje mierenneuken

[whoami]

P_de_B schreef op donderdag 31 maart 2005 @ 16:36:
[...]

Ik denk dat 'ie partitioned views bedoeld?

Dat bedoelde ik eigenlijk ook.

[Verwijderd]

Oh oh...daar gaan we weer

In enigszins gerelateerd nieuws: gisteren is de beta van MySQL 5.0 uitgekomen waarin voor het eerst sprocs, triggers en views zitten. Om David Axmark van MySQL te citeren (ZDNET):

"People have been criticising MySQL since we started [in 1995] for not having stored procedures, triggers and views," said Axmark. "We're fixing 10 years of criticism in one release."

Of, zoals ze bij Slashdot zeggen:

It's like it'll be a real DB!

Slecht of niet, er is blijkbaar wel degelijk behoefte aan deze zaken....

[Verwijderd]

Waarom volledig ja of nee zeggen als er ook een gulde middenweg bestaat? Hoe vaak schrijf je een applicatie die daadwerkelijk generiek op vele verschillende systemen moet draaien? Hoe genereer je primaire sleutels, progmatisch?

Verder loop ik nooit zo warm voor performance. Een dag bezig zijn met optimaliseren kost even veel als een compleet nieuwe server. Bruikbaarheid van de code heeft dus wat mij betreft voorrang.

[Annie]

Verwijderd schreef op donderdag 31 maart 2005 @ 18:24:
Verder loop ik nooit zo warm voor performance. Een dag bezig zijn met optimaliseren kost even veel als een compleet nieuwe server. Bruikbaarheid van de code heeft dus wat mij betreft voorrang.

Je vergeet dat een nieuwe server ook ingericht moet worden. En daarnaast ook meer beheer kost, meer backup-space, misschien extra rackspace, zwaardere airco, extra netwerkinfrastructuur, enz.
Als het zo simpel was zou elke IT manager, zonder er enig probleem van te maken, extra servers aanschaffen. En toch doen ze dat niet.

[Verwijderd]

Wat is er mis met stored procs?

Voorbeeld 1:
Je houdt in je database netjes bij hoeveel fietsen, strandstoelen, parasols, etc. per dag verhuurd zijn. Leuk, maar nu wil de klant een maandoverzicht.
Dan kun je je in 3 bochten wringen om client side die data op te halen en te formatteren, met als gevolg dat de client applicatie overal moet worden geupdate, maar met een stored proc is 't 1 kleine database update en een nieuw rapportje.

Voorbeeld 2:
Stel, je ontwikkeld voor meerdere databases.
InterBase kent geen autoincrementing fields, en MSSQL heeft geen flauw benul van generators. Dan is een stored proc die beide ondersteunt best wel handig.

[JaQ]

mayonaise schreef op donderdag 31 maart 2005 @ 16:19:
Zodra je iemand ooit een compleet workflowsysteem in HTML hebt zien rondmailen vanuit stored procedures weet je weer waarom ze kut zijn.

maar dat is dan ook een prototype van "hoe doe ik het niet". Kijk voor de grap eens naar HTMLDB (van oracle). Daarmee kan je een website bouwen mbv stored procedures (via de al oude web util toolkit voor plsql, oftewel een mod_plsql voor apache). Een stored proc maken die je layout afhandeld (en css etc. etc.) icm met wat tabellen met je data (bv inhoud van css) kan prima en is imho zeker niet fout. Grootste voordeel (en nou ga ik ruzie maken): geen noodzaak voor (o.a.) bloated java programmeur die af lopen te geven op DBA's "omdat die niet kunnen ontwikkelen". _{deze semi-dba voelt zich dus aangesproken en op z'n pik gertapt. Misschien wel omdat ik ook al jaren ontwikkeld heb en tegenwoordig meer analist ben dan DBA} Traditionele DBA's die alleen een database kunnen managen zijn dinosaurussen die bijgeschoold moeten worden en daar is binnen nu en 5 jaar geen plaats meer voor. (imnsho)

mayonaise schreef op donderdag 31 maart 2005 @ 16:19:
Stored procedures zijn imho voor maintenance operaties, scheduled jobs en andere terugkerende acties die op z'n tijd al of niet handmatig uitgevoerd moeten worden. Voor applicatiedevelopment is het gewoon een crime in maintenance (altijd leuk als je een localhost, devserver, testserver en productieserver moet updaten met verschillend geversioneerde SP's) en zijn ze gewoon niet op hun plaats. Een database moet data opslaan, de DB-layer van de applicatie moet het beheren. En beheert dus de queries.

mayonaise schreef op donderdag 31 maart 2005 @ 16:23:

En federated views in SQL Server Enterprise

gepartitioneerde tabellen (in oracle enterprise server) is anders ook niet verkeerd (scheelt weer zo'n klote view )

mayonaise schreef op donderdag 31 maart 2005 @ 16:23:
Dat los je imho op met een 3-tier model, waarbij de applicaties tegen een service aanpraten die de data beheert en als enige ter wereld de database in kan.

[/quote]

en die "service" kan natuurlijk bestaan uit stored procedures Je voert dus geen DML uit, maar roept een SP aan. Ik zeg niet dat het heilig is, maar het is imho ook niet verkeerd.

_{damn... ik moet je wel hebben}

[Verwijderd]

Annie schreef op donderdag 31 maart 2005 @ 22:55:
[...]

Je vergeet dat een nieuwe server ook ingericht moet worden. En daarnaast ook meer beheer kost, meer backup-space, misschien extra rackspace, zwaardere airco, extra netwerkinfrastructuur, enz.
Als het zo simpel was zou elke IT manager, zonder er enig probleem van te maken, extra servers aanschaffen. En toch doen ze dat niet.

idd. Vergeet ook niet dat een beetje server, zeker als ie sneller moet zijn dan de oude (die je als je jouw visie volgt nog niet zo lang hebt), toch al snel zo'n 2000 euro kost minimaal. Zit je op een goede quad DB bak dan is 10.000 meer het minimum.

Als jij 2000 euro per dag verdient, dan wil ik graag eens even met je baas gaan babbelen.

[whoami]

Scott Bellware's commentaar nav de RedGate mail.
Zijn 'point of view' is wel goed, en hij raakt ook de essentie.

[ Voor 27% gewijzigd door whoami op 01-04-2005 09:20 ]

[EfBe]

Niet weer... wanneer gaan mensen eens ophouden met deze non-discussie...
Bedankt voor de link, Whoami, Scott heeft het begrepen.

[Kwistnix]

Er zijn genoeg argumenten tegen het gebruik en genoeg argumenten voor het gebruik van stored procedures, maar mijns inziens is het toch de situatie die dicteert of het gebruik van stored procedures wel of geen goede oplossing is. SP's zijn een middel; geen doel.

[ Voor 3% gewijzigd door Kwistnix op 08-04-2005 17:25 ]

[NMe]

Op verzoek een post van leeko verwijderd, omdat deze hier een nieuw topic over heeft geopend.

[Verwijderd]

Verwijderd schreef op vrijdag 01 april 2005 @ 00:43:
idd. Vergeet ook niet dat een beetje server, zeker als ie sneller moet zijn dan de oude (die je als je jouw visie volgt nog niet zo lang hebt), toch al snel zo'n 2000 euro kost minimaal. Zit je op een goede quad DB bak dan is 10.000 meer het minimum.

Als jij 2000 euro per dag verdient, dan wil ik graag eens even met je baas gaan babbelen.

Ohja dit was tweakers heh, mijn fout. Hier lezen de meeste mensen alles letterlijk waar af en toe ook figuurlijk gelezen dient te worden. Ik gooi deze post maar onder het kopje sarcasme...