Wann Stored Procedure nutzen?

[Hansa]

Deshalb habe ich das ja geschrieben. 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 von jobo:

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 ?

[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