Verwijderd schreef op 22 November 2002 @ 12:00:
[...]
Het maken van scheiding tussen verschillende soorten code is binnen een ontwikkeltaal/-omgeving vaak goed mogelijk. Denk aan functies of classes. Daar heb je niet specifiek SPs voor nodig
SP's kun je niet vergelijken met functies of classes. Een SP gaat enkel bewerkingen doen op een databank.
Hier zit een kern van waarheid in. In sommige situaties is code dat in een ontwikkelomgeving 100 regels zou kosten in een SP in 20 regels op te lossen.
+ dat het performanter zal zijn.
Dat zie ik niet. Waarom zou mijn code moeilijker aanpasbaar worden?
Omdat jij, als je datamodel verander, al jouw source-files zult moeten overlopen, alle sql-statements zult moeten controleren en eventueel aanpassen en al je programma's opnieuw moet compileren.
Als je gebruik maakt van SP's, pas je gewoon je SP's aan en that's it.
Mijns inziens is het juist makkelijk om zowel mijn SQL code als mijn andere code in 1 omgeving en 1 taal te bewerken.
Maar SQL is een andere taal dan de taal waarin je jouw business logic schrijft. Trouwens, de manier om een SP aan te roepen of om een plain sql-query uit te voeren is identiek.
Nadeel voor het aanpassen van een SP is juist dat je een andere ontwikkelomgeving moet openen om dat te doen.
't Is maar wat jij een nadeel vind en of je bereid bent om eventuele opofferingen te maken om gebruik te kunnen maken van bepaalde voordelen die minstens opwegen tegen die nadelen.
En wat is daar erg aan?
Zoals ik eerder al zei: security.
Je wilt niet dat de tabelnamen van jouw databank bekend zijn. Het uitvoeren van SQL queries in je code implliceert ook dat de gebruiker het recht moet hebben om queries uit te voeren. Als hij toegang heeft tot de databank kan hij, als hij de tabelnamen weet dus gewoon willekeurige queries gaan uitvoeren en/of data gaan manipuleren.
Doe je het met SP's, dan hoef je de gebruiker enkel het recht te geven om SP's uit te voeren. De queries die mogen uitgevoerd worden liggen vast in die SP's.
Voor de 3e of 4e keer: ik zeg niet dat er geen voordelen zijn, sterker nog, daarin ben ik het met de eerdere opmerkingen eens. Ik zeg alleen dat er een nadeel is, wat je niet zou moeten tegenhouden, maar waar je wel rekening mee moet houden.
Dat weet ik wel.
Jij hebt ongetwijfeld weleens in ASP met VBScript geprogrammeerd, en vervolgens ook wat JavaScript functies in de pagina gezet. Plots zet je Dim in je JavaScript, en vergeet je de puntkomma's, of andersom bij VBScript. Ergo: je moet nadenken over welke taal je gebruikt, en switchen levert problemen op.
Tja, dat is een miniem probleem. Je compiler zal je wel zeggen dat iets niet kan, en dan moet je euro wel vallen. Je moet er gewoon met je gedachten blijblijven.
Als je weet dat je met T-SQL bezig bent, dan zal je wel geen C# / pascal / C++ code ertussen schrijven.
Met Stored Procedures moet je dan ook de hele tijd heen en weer switchen tussen editors.
Tja, als jij een document typed en een spreadsheet hebt, moet je ook wel eens switchen.
Ook is het moeilijker overzicht te krijgen in wat voor functionaliteit je al ontwikkeld hebt. Ik weet niet of je veel ervaring hebt in het werken met teams van ontwikkelaars, maar in dat geval zie je vaak dat er bijvoorbeeld dubbele stored procedures worden gemaakt omdat niet duidelijk is wat welke stored procedure doet, of dat stored procedures worden aangepast voor doeleinden waarvoor ze niet bedoeld zijn. Op het eerste gezicht lijkt dat 'stom', maar dat gebeurt gewoon.
Dat is stom idd.
Er moet gewoon voldoende communicatie zijn tussen de verschillende teams en ontwikkelaars. Er moeten duidelijke afspraken zijn wie wat doet en er moeten consistente naming-conventions zijn. Dan kun je al zo'n dingen vermijden.
Als je trouwens een SP schrijft en die blijkt fout te zijn, dan moet je maar 1 SP aan passen. Schrijf je een query die bepaalde data ophaalt en gebruik je die als plain SQL in je code, dan mag je al jouw code gaan overlopen en gaan zoeken of hij juist is of niet. (Trouwens, geen gebruik maken van SP's zorgt er ook voor dat code gedupliceerd wordt).
'The right tool for the job' gaat deels op, maar dit is een oversimplificatie. Tools zoals een hamer of een zaag hebben geen leercurve en zijn makkelijk conceptueel van elkaar te scheiden. Niemand zal een hamer voor een zaag zien en andersom.
Het is idd misschien wel wat simpel, maar to the point.
Mijn advies: lees nogmaals het dik gedrukte deel hierboven, dan laat ik het verder hierbij voor deze discussie, want ik ben alleen maar mijn argumenten aan het herhalen en uitbreiden, en jij ook.
Ik wil je gewoon doen inzien dat het nadeel dat jij vernoemt eigenlijk geen nadeel mag zijn, en men wel eens verder moet kijken naar wat mogelijk is.
Ik gebruikte vroeger ook nauwelijks/geen SP's, maar ben nu volledig 'bekeerd'.
Verder snap ik jouw punt wel hoor.
/u/1934/av-559.png?f=community)
/u/38325/avatar.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/17982/morpheus.jpg?f=community)
Die leiden gewoon tot onoverzichtelijkheid en op den duur gaat iedereen maar door elkaar blaten zonder dat men nog weet waar het precies over gaat.
:strip_icc():strip_exif()/u/69009/eend.jpg?f=community)