In tegenstelling tot de eigenlijke programmeertaalcode, doen ze:
- niet draagbaar (elke db heeft zijn eigen versie van PL/SQL. Soms verschillende versies van dezelfde database zijn incompatibel - ik heb het gezien!)
- niet gemakkelijk te testen - je hebt een echte . nodig (dev) database-instantie om ze te testen en dus het testen van hun code als onderdeel van een build is vrijwel onmogelijk
- niet gemakkelijk bij te werken/uit te brengen - u moet ze verwijderen/aanmaken, dwz aanpassen de productie-db om ze vrij te geven
- geen bibliotheekondersteuning hebben (waarom code schrijven als iemand anders dat wel heeft)
- zijn niet gemakkelijk te integreren met andere technologieën (probeer een webservice van hen te bellen)
- ze gebruiken een taal die ongeveer net zo primitief is als Fortran en zijn daarom onelegant en arbeidsintensief om bruikbare codering gedaan te krijgen, dus het is moeilijk om bedrijfslogica uit te drukken, ook al is dat meestal hun primaire doel
- bied geen debugging/tracing/message-logging etc aan (sommige databases ondersteunen dit mogelijk - ik heb het echter niet gezien)
- het ontbreekt aan een fatsoenlijke IDE om te helpen met syntaxis en om te linken naar andere bestaande procedures (bijvoorbeeld zoals Eclipse doet voor java)
- mensen die bedreven zijn in het coderen ervan zijn zeldzamer en duurder dan app-codeerders
- hun "hoge prestatie" is een mythe, omdat ze worden uitgevoerd op de databaseserver die ze gewoonlijk verhogen de belasting van de db-server, dus het gebruik ervan zal gewoonlijk verminderen uw maximale transactiedoorvoer
- onvermogen om constanten efficiënt te delen (normaal opgelost door een tabel te maken en deze vanuit uw procedure op te zoeken - zeer inefficiënt)
- enz.
Als u een zeer database-specifieke actie heeft (bijvoorbeeld een actie tijdens een transactie om de db-integriteit te behouden), of uw procedures zeer atomair en eenvoudig houdt, zou u ze misschien kunnen overwegen.
Voorzichtigheid is geboden bij het vooraf specificeren van "hoge prestaties". Het leidt vaak tot slechte keuzes ten koste van een goed ontwerp en het zal je veel eerder bijten dan je denkt.
Gebruik opgeslagen procedures op eigen risico (van iemand die er is geweest en nooit meer terug wil). Mijn aanbeveling is om ze te vermijden als de pest.