Wann Stored Procedure nutzen?

[fkerber]

Hi,

eine (vielleicht doofe) Frage:
Wann setze ich Stored Procedures ein und wann nicht?

Nehmen wir folgendes Beispiel:
Ich mache ein Insert in eine Tabelle und lasse mir die erzeugte (Generator, Trigger) ID zurückgeben und füge diese zusammen mit anderen Daten in eine zweite Tabelle ein.
Das habe ich jetzt momentan in einer SP ausgelagert, sodass ich nur einen Aufruf habe.
Da hätte ich jetzt spontan gesagt, dass es sinnvoll war, das so "auszulagern". (Oder etwa schon nicht?)

Jetzt ist aber die Frage für mich, ab "wann" macht man ne SP? Sobald es über ein schnödes Insert/Update/Delete hinausgeht?
Oder erst ab einer gewissen Komplexität? Und da wäre dann die Frage, wie definiert sich / ihr das?


LG, Frederic

[-187-]

Naja eine Stored Procedure ist immer dann sinnvoll wenn du den selben "langen" Code öfters aufrufen musst. Du erhöhst damit die Geschwindigkeit deiner Anwendung (wenn auch nur minimal) weil der Datenaustausch der Anwendung und des DBMS einfach gesagt auf eine zeile (CALL oder EXECUTE) beschränkt wurde.

Das ist aufjedenfall schonmal ein Grund :P

[jobo]

Bei der Datenhaltung (Insert/Update/Delete) wäre es
- Performance
- Gewährleistung der Integrität (komplexe Insert, - Update, .. wo referentielle Integrität und Constraints aufhören)
- daraus abgeleitet oder ähnlich, die Schaffung eines scharf definierten Interfaces (wenn nötig)

Bei Datenverarbeitung
- zentrale, gezielte, definierte, performante Datenverarbeitung

Gegenanzeigen:
breite Interfaces/Parameterlisten
Bei Tabellen mit sehr vielen Feldern ist es angenehm, diese normal per SQL nach Bedarf zu bearbeiten. Wenn also die Datenqualität nicht gefährdet ist, gern ohne Stored Proc.

Ach und noch was, bevor ich irgendeine Logik im Client hab, dann doch lieber auch eine Stored Proc. Es sei denn das hat taktische Gründe ...

[mkinzler]

Es entfällt auch die "Kompillierung" der Abfarge und die Bildung des Plans

[Hansa]

Dann, wenn längere Berechnungen ausgeführt werden müssen. Mit Rückgabewerten etc.

Ganz anderes Einsatzgebiet :

Code:

  AENDERN = -1;
  SELECT ID FROM TABLEX WHERE ID_X= :ID_X INTO :AENDERN;
  IF (AENDERN < 0) THEN BEGIN
    INSERT INTO TABLEX (ID_Y) VALUES (:ID_Y);
  END
  ELSE BEGIN
    UPDATE TABLEX SET ID_Y = :ID_Y;
  END

Da soll die DB gefälligst selber wissen, ob Update oder Insert nötig ist.

[mkinzler]

Wobei das auch mit einem

SQL-Code:

Update or insert

gehen würde

[Hansa]

Und das ein Beispiel ist,

[fkerber]

Hi,

danke für eure Antworten.
Dann frage ich mal noch ander:
Wann sollte man keine SP benutzen, bzw. was ist der Nachteil bei dem, was jobo hier ansprach:

Zitat:

Zitat von jobo (Beitrag 1087460)

Gegenanzeigen:
breite Interfaces/Parameterlisten
Bei Tabellen mit sehr vielen Feldern ist es angenehm, diese normal per SQL nach Bedarf zu bearbeiten. Wenn also die Datenqualität nicht gefährdet ist, gern ohne Stored Proc.

LG, Frederic

[mkinzler]

Bei variabler Anzahl von Parametern (in und/oder out)

[hoika]

Hallo,

1. Nachteil ist die Pflege.
Gerade, wenn eine SP1 eine SP2 benutzt und man in der SP die Parameter ändert
-> rumms

2. Nachteil
wieder Pflege
Ändern einer SP (neuer Parameter).
Woran erkennt man, dass die SP schon geändert wurde ?
OK, System Tables, wer es weiss ;)
Hier hilft nur genaue Doku und Mitführen einer DB-Id

3. Nachteil war (bis vor 2.5 ?), dass man keine Domains als Parameter verwenden konnte.


Was als Vorteil noch nicht genannt wurde (oder ich habe es überlesen).
Thema Sicherheit
Ich kann einem User die Rechte an einer Tabelle komplett wegnehmen,
ihm aber die Rechte an einer SP geben, die eine paar Spalten, oder was auch immer
dieser Tabelle zurückgibt.



Heiko
aus dieser Tabelle

Heiko

[-187-]

Hm ja Heiko hat noch ein ganz wichtiges Thema genannt.

Eine Stored Procedure wird auch benutzt um eine kontrollierte Manipulation der Daten zu gewährleisten.

Bzw. eine Manipulation der Daten in Bereichen in dem der normale Anwender keine Rechte hat. (zB Löschen von Daten)

[tsteinmaurer]

Folgende Punkte sind eine "Warum solch ich serverseitige Sachen (Procedures/Trigger) verwenden" Liste aus meinen Vorträgen:

- Run code on any Firebird platform unchanged
- Make the same code for different connectivity technologies available
- Reduce network traffic
- Centralize business logic
- Improve query execution, because pre-compiled server-side code is stored in the database system tables
- Data abstraction layer
- Ensure customized data integrity
- Enforce business rules
- Build a server-side logging/auditing mechanism
- Notify client applications upon certain events
- Data model checking routines
- Create complex calculation routines
- Create your own functions without using an UDF
- The procedural language PSQL is easy to learn, easy to use and powerful


Wird sicherlich nicht vollständig sein ... ;-)

[Hansa]

Zitat:

Zitat von tsteinmaurer (Beitrag 1087493)

Folgende Punkte sind eine "Warum solch ich serverseitige Sachen (Procedures/Trigger) verwenden" Liste aus meinen Vorträgen:

- Run code on any Firebird platform unchanged

Da muss man aber dazu sagen, dass das "unchanged" sich auf Delphi bezieht, sofern der SQL-Code der SP nicht DB-seitig geändert wurde ! Also andere Parameterliste usw. Woher soll das Programm ohne Änderungen wissen, dass da andere Daten zurückgeliefert werden ? Oder mache ich da Denkfehler ?

[mkinzler]

Nein, eher ob auf Windows, Linux oder MacOSX

[Hansa]

Andere Betriebssysteme sind ja wohl klar. Und was ist das ::shock:

Zitat:

---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt pro.exe ist eine Exception der Klasse EFIBInterBaseError aufgetreten. Meldung: 'DMod.SchreibeSP:
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements.
Dynamic SQL Error.
Input parameter mismatch for procedure SCHREIBE_SP8.
'. Prozess wurde angehalten. Mit Einzelne Anweisung oder Start fortsetzen.
---------------------------
OK Hilfe
---------------------------

Muss ich jetzt Mac kaufen, um zu sehen, dass da auch so ist ?

Edit : habe lediglich in SP neuen Parameter angelegt (mit IBExpert), ohne am Programm was zu ändern.

[mkinzler]

Von Parameterunabhängigkeit hat Thomas nichts geschrieben

[Hansa]

Deshalb habe ich das ja geschrieben. :mrgreen: Da muss man schon aufpassen. Auch das mit den Domains kommt mir etwas zu kurz. Es besteht eine gewisse Vorliebe alles Dephi-ähnlich über Typen (Domains nur ähnlich, nicht identisch !!) zu regeln und die dann als Parameter zu übergeben (was Domains aber nicht leisten). Auch da ist Gefahr im Verzug. Zumindest < FB 2.5.

[jobo]

Die Erweiterung von StoredProcedures ist ja eine recht spezifische Konstellation und durchaus vergleichbar mit alter Table statements, die in einem SQL auch nicht automatisch berücksichtigt sind.

Daher weiß ich nicht ob das nun ein pro oder contra sein könnte.

Wenn man bei neuen Parametern mit Defaultwerten arbeitet und sie entsprechend positioniert, kann man das Thema ja umschiffen.

[jobo]

Im übrigen bietet eine Vorbelegung von Parametern auch bei dieser Frage

Zitat:

Wann sollte man keine SP benutzen, bzw. was ist der Nachteil bei dem, was jobo hier ansprach:

noch etwas Luft.

[Hansa]

Zitat:

Zitat von jobo (Beitrag 1087511)

Im übrigen bietet eine Vorbelegung von Parametern auch bei dieser Frage
..noch etwas Luft.

Nein, die Luft ist weg. Die Definition der Datenbank stimmt nicht mehr mit der im Programm überein ! Warum soll das was nützen, etwas dem Programm unbekanntes vorzubelegen, wenn es nicht mal definiert ist ? :shock:

[hoika]

Halo,

Delphi-Quellcode:

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 :pale:

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