Wann Stored Procedure nutzen?

[hoika]

Halo,

Wenn man bei neuen Parametern mit Defaultwerten arbeitet und sie entsprechend positioniert, kann man das Thema ja umschiffen. Ich hatte eher an das Ändern existierender Parameter gedacht.

Bsp:
Feld ändert sich von Char(50) auf Char(100).

Wird die SP nicht geändert, knallt es bei dem 1. Feld, was größer 50 Zeichen hat.


Heiko

[jobo]

Meine Beispiele mit vorbelegten Parametern beziehen sich auf ein neues Interfaces, das mit einem alten koexistieren kann.
Sinn macht das eher nur, wenn es auch eine neue Anwendung gibt, die das nutzt.
Denkbar wäre auch noch eine Konstellation mit SP, die sich intern aufrufen, also gar nicht für die Anwendung gedacht sind.

Wenn sowieso nur von einer Anwendung die Rede war, versteh ich nicht, was die Änderung einer SP so dramatisch von einer bloßen DM Änderung unterscheidet, die ohne SP per Insert/Update/Delete bearbeitet wird. Ich muss im Zweifel immer prüfen und die Anwendung anpassen, besonders wenn ich in der Anwendung mit Feldpersistenz arbeite.
Ok, wenn ich in einer Tabelle ein Feld ändere und das wird in einer SP übergeben, dann muss ich den Parameter halt auch ändern, in allen SP die das Feld übergeben oder diese SP aufrufen.
Wenn ich an der Stelle mit Domains arbeite, hab ich es vielleicht einfacher.
Das kommt mir aber etwas wie Mücke und Elefant vor.

Letztlich steht das Thema hinter der Integrität zurück.
Zentrale Logik im Server statt im Client- also u.a. in SP- ist viel höher anzusiedeln, als der geringere Entwicklungskomfort bei einer Parameter Typ Änderung.

[mkinzler]

Wenn man die Parameter einer lokalen Prozedur/Funktion/Methode ändert, knallt es auch, oder bei Interfaceänderungen in einer Dll.
Das würde ich jetzt nicht als Nachteil einer SP ansehen

[borwin]

Vorteile ist eine klare Trennung bei der Verarbeitung der Daten und der Eingabe und Ausgabe der Daten
Wenn alles in SP abgebildet wird kann ich die Struktur einer DB einfacher ändern ohne das die Clints
berücksichtig werden müssen. Vorausgesetzt ich ändere nicht die Schnittstellen selber.
Durch die SP habe ich eine klare Abgrenzung. Bei Parameteränderungen muss ich reagieren
aber auch beim Ändern z.B. einer Feldlänge einer Spalte.
Ein weiterer Vorteil ist wenn ich das Frontend mal ändern muss. Z.B. umsteigen auf eine
Webapplikation. Das ist schon deutlich einfacher.
Was noch nicht erwähnt wurde ist das SQL-Injection. das sollte mit SP nach meinem Wissen nicht möglich sein.
O.K. außer ich verwende vielleich dynamisches SQL

Ein Nachteil ist, wenn mehrere DB unterstützt werden sollen. Dann hört der Spaß auf.

Gruß BORWIN

[mkinzler]

Zitat:

Ein Nachteil ist, wenn mehrere DB unterstützt werden sollen. Dann hört der Spaß auf.

Das soll sich aber ändern.

Man kann durch die Verwendung von SPs dass Programm auch leichter cross-DBMS-fähig machen

[hoika]

Hallo,

Zitat:

Wenn man die Parameter einer lokalen Prozedur/Funktion/Methode ändert, knallt es auch

Ändere ich in Delphi die Parameter, meldet sich meist der Compiler.
Bei einer SP habe der genervte Nutzer ...

Aber das lässt sich alles in der Griff bekommen (DB-Version mitführen)

Was ich aber als grossen Nachteil bei FB sehe,
die fehlende Möglichkeit, eine SP zu debuggen.
OK, IBExpert (Proff.) baut das nach,
aber warum hat FB kein Debug-Interface wie z.B. MS.
*auf Version 4 wart und hoff*


Heiko

[tsteinmaurer]

Ist zwar nicht debuggen, aber man kann sich eine Art Debug-Log einer Stored Procedure relativ einfach mitschreiben. So z.B. in ein EXTERNAL TABLE oder halt in reguläre Tabellen mit AUTONOMOUS TRANSACTION. In Verbindung mit CURRENT_CONNECTION etc. kann man dann das Ganze "isolieren". Der Debug-Modus kann dann halt über ein Flag in einer Tabelle oder über eine User-Session Variable aktiviert bzw. deaktiviert werden. Etwas Mehraufwand, aber für kritische/komplexe Prozeduren auch für Produktivumgebungen fast ein Muss.

Thomas