Na rozdíl od skutečného kódu programovacího jazyka:
- nepřenosné (každá databáze má svou vlastní verzi PL/SQL. Někdy různé verze stejného databáze jsou nekompatibilní – viděl jsem to!)
- nesnadno testovatelné – potřebujete skutečný (dev) instance databáze k jejich otestování a tedy jednotkovému testování jejich kódu v rámci sestavení je prakticky nemožné
- nesnadno aktualizovatelné/uvolnitelné – musíte je zahodit/vytvořit, tj. upravit produkční databáze, aby je uvolnila
- nemají podporu knihoven (proč psát kód, když ho má někdo jiný)
- nejsou snadno integrovatelné s jinými technologiemi (zkuste z nich zavolat webovou službu)
- používají jazyk asi tak primitivní jako Fortran, a proto jsou neelegantní a pracné při vytváření užitečného kódování, takže je obtížné vyjádřit obchodní logiku, i když to je obvykle jejich primární účel
- nenabízejí ladění/sledování/protokolování zpráv atd. (některé databáze db to mohou podporovat – já jsem to však neviděl)
- chybí slušné IDE, které by pomohlo se syntaxí a propojením s jinými existujícími procedurami (např. jako Eclipse pro java)
- Lidé zběhlí v jejich kódování jsou vzácnější a dražší než kodéři aplikací
- jejich "vysoký výkon" je mýtus, protože spouštějí na databázovém serveru, který obvykle zvyšují zatížení db serveru, takže jejich používání obvykle sníží vaše maximální transakční propustnost
- neschopnost efektivně sdílet konstanty (běžně se to řeší vytvořením tabulky a jejím dotazováním ze své procedury – velmi neefektivní)
- atd.
Pokud máte akci velmi specifickou pro databázi (např. akci v rámci transakce pro zachování integrity databáze), nebo pokud máte své postupy velmi atomické a jednoduché, možná byste je mohli zvážit.
Při zadávání „vysokého výkonu“ dopředu se doporučuje opatrnost. Často to vede ke špatným volbám na úkor dobrého designu a kousne vás mnohem dříve, než si myslíte.
Používejte uložené procedury na vlastní nebezpečí (od někoho, kdo tam byl a nikdy se nechce vrátit). Moje doporučení je vyhýbat se jim jako moru.