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