Ik ben geen fan van opgeslagen procedures
Opgeslagen procedures zijn MEER te onderhouden omdat:* u uw C#-app niet opnieuw hoeft te compileren wanneer u wat SQL wilt wijzigen
Je zult het hoe dan ook opnieuw compileren wanneer datatypes veranderen, of je wilt een extra kolom retourneren, of wat dan ook. Het aantal keren dat u de SQL 'transparant' onder uw app kunt wijzigen, is over het algemeen vrij klein
- U gebruikt uiteindelijk SQL-code opnieuw.
Programmeertalen, inclusief C#, hebben iets geweldigs, een functie genaamd. Het betekent dat je hetzelfde codeblok op meerdere plaatsen kunt oproepen! Verbazingwekkend! Je kunt dan de herbruikbare SQL-code in een van deze plaatsen, of als je echt hightech wilt worden, kun je een bibliotheek gebruiken die het voor je doet. Ik geloof dat ze Object Relational Mappers worden genoemd en dat ze tegenwoordig heel gewoon zijn.
Het herhalen van codes is het slechtste wat je kunt doen als je een onderhoudbare applicatie probeert te bouwen!
Mee eens, daarom zijn opgeslagenprocs een slechte zaak. Het is veel gemakkelijker om code te refactoren en te ontleden (in kleinere delen op te splitsen) in functies dan SQL in... blokken SQL?
Je hebt 4 webservers en een heleboel Windows-apps die dezelfde SQL-code gebruiken. Nu realiseer je je dat er een klein probleem is met de SQL-code, dus wil je liever...... verander de proc op 1 plaats of push de code naar iedereen de webservers, installeer alle desktop-apps opnieuw (een keer klikken kan helpen) op alle Windows-boxen
Waarom maken uw Windows-apps rechtstreeks verbinding met een centrale database? Dat lijkt een ENORM beveiligingslek daar, en een bottleneck omdat het server-side caching uitsluit. Zouden ze geen verbinding moeten maken via een webservice of vergelijkbaar met uw webservers?
Dus, push 1 nieuwe sproc, of 4 nieuwe webservers?
In dit geval is het is gemakkelijker om één nieuwe sproc te pushen, maar in mijn ervaring heeft 95% van de 'gepushte wijzigingen' invloed op de code en niet op de database. Als je die maand 20 dingen naar de webservers pusht en 1 naar de database, verlies je nauwelijks veel als je in plaats daarvan 21 dingen naar de webservers pusht en nul naar de database.
Gemakkelijker code beoordeeld.
Kun je uitleggen hoe? Ik snap dit niet. Vooral omdat de sprocs waarschijnlijk niet onder bronbeheer staan en daarom niet toegankelijk zijn via webgebaseerde SCM-browsers enzovoort.
Meer nadelen:
Storedprocs leven in de database, die voor de buitenwereld als een zwarte doos verschijnt. Simpele dingen, zoals ze in bronbeheer willen zetten, worden een nachtmerrie.
Er is ook de kwestie van pure inspanning. Het is misschien logisch om alles op te splitsen in een miljoen niveaus als je je CEO probeert te rechtvaardigen waarom het hen slechts 7 miljoen dollar heeft gekost om een aantal forums te bouwen, maar anders is het maken van een opgeslagen proces voor elk klein ding gewoon extra ezelwerk voor geen voordeel.