Im Gegensatz zum eigentlichen Programmiersprachencode:
- nicht portabel (jede Datenbank hat ihre eigene Version von PL/SQL. Manchmal verschiedene Versionen derselben selben Datenbank sind inkompatibel - ich habe es gesehen!)
- nicht leicht testbar - Sie brauchen eine echte (dev)-Datenbankinstanz, um sie zu testen, und somit ist es praktisch unmöglich, ihren Code als Teil eines Builds zu testen
- nicht leicht aktualisierbar/veröffentlichbar - Sie müssen sie löschen/erstellen, dh modifizieren die Produktionsdatenbank, um sie freizugeben
- keine Bibliotheksunterstützung haben (warum Code schreiben, wenn jemand anderes hat)
- sind nicht leicht in andere Technologien integrierbar (versuchen Sie, einen Webdienst von ihnen aufzurufen)
- Sie verwenden eine Sprache, die ungefähr so primitiv wie Fortran ist, und sind daher unelegant und mühsam, um nützliche Codierungen zu erstellen. Daher ist es schwierig, Geschäftslogik auszudrücken, obwohl dies normalerweise ihr Hauptzweck ist
- bieten kein Debugging/Tracing/Message-Logging etc. an (einige Datenbanken unterstützen dies möglicherweise - ich habe es aber nicht gesehen)
- fehlt eine anständige IDE, um bei der Syntax und der Verknüpfung mit anderen bestehenden Prozeduren zu helfen (z. B. wie Eclipse es für Java tut)
- Personen, die sich mit der Programmierung auskennen, sind seltener und teurer als App-Programmierer
- Ihre "hohe Leistung" ist ein Mythos, da sie auf dem Datenbankserver ausgeführt werden, den sie normalerweise steigern die Belastung des DB-Servers, daher wird ihre Verwendung normalerweise reduzieren Ihr maximaler Transaktionsdurchsatz
- Unfähigkeit, Konstanten effizient gemeinsam zu nutzen (normalerweise gelöst durch Erstellen einer Tabelle und Abfragen innerhalb Ihrer Prozedur - sehr ineffizient)
- usw.
Wenn Sie eine sehr datenbankspezifische Aktion haben (z. B. eine In-Transaction-Aktion, um die DB-Integrität aufrechtzuerhalten) oder Ihre Prozeduren sehr atomar und einfach halten, könnten Sie sie vielleicht in Betracht ziehen.
Vorsicht ist geboten, wenn man von vornherein „hohe Leistung“ angibt. Es führt oft zu schlechten Entscheidungen auf Kosten eines guten Designs und wird Sie viel früher beißen, als Sie denken.
Verwenden Sie gespeicherte Prozeduren auf eigene Gefahr (von jemandem, der dort war und nie wieder zurückkehren möchte). Meine Empfehlung ist, sie wie die Pest zu meiden.
