Stored Procedures für CRUD Operationen?

[mquadrat]

Hallo zusammen,

mich würde mal interessieren wie Ihr CRUD Operationen (Insert, Select, Update, Delete) ausführt. Bislang habe ich die entsprechenden Statements immer direkt in den Code geschrieben. Wenn man aber ein paar der MSDN Artikel liest wird dort immer gesagt, dass alle Operationen in Stored Procedures durchgeführt werden.

Nachteil dieses Vorgehens ist ganz klar, dass man immer Program und SP ändern muss, wenn neue Felder hinzukommen. Wobei das Generieren der SPs ja auch automatisiert werden kann. Andererseits verspricht der Einsatz von SPs eine bessere Performance, da die Statements ja schon prepared und optimiert in der DB vorliegen.

Daher die Frage, wie macht Ihr das bzw. was haltet Ihr warum für besser?

[mkinzler]

SPs machen imho nur Sinn, wenn die Aktionen komplexer sind.

[mquadrat]

So habe ich das bislang auch gehandhabt. Bei einer Datenbank mit 100 Tabellen wären das ja alleine schon min. 400 SPs, was die ganze Angelegenheit etwas unübersichtlich macht. Bei Microsoft scheinen die SPs aber wohl zu den best practices zu gehören.

[TBx]

Generell übers SPs zu arbeiten macht meiner Meinung nach gar keinen Sinn. Auch der Aufruf der SPs muss ja vorher prepared werden, sodass es Dir überhaupt keinen Geschwindigkeitsvorteil bringt, senn Du

SQL-Code:

select dies, das from irdendwo

in eine Stored Procedure packst. Die müßtest DU dann ja auch über

SQL-Code:

select dies, das from MyStoredProc

aufrufen. Gewinn also gleich null.

Es wird in diversen Artikeln preferriert mit SPs zu arbeiten, da man damit wirkungsvoll SQL-Injection vermeiden kann. Das läßt sich aber durch umsichtige Programmierung meist auch anders lösen.

Gruß
Thomas

[mquadrat]

Ein Hauptgrund für das Verwenden von SPs scheint zu sein, dass damit der Datenbankadmin die volle Kontrolle über die ausgeführten Queries behält und sie nich an den Entwickler abgeben muss. Der DBA hat also volle Kontrolle über alle Aspekte der Datenbank. Ob das allerdings den Overhead für Erstellung und Wartung rechtfertigt sei mal dahin gestellt.

Eine recht umfangreiche Diskussion findet sich übrigens hier TheServerSide.net

[MrSpock]

Also ich halte den Vorschlag in den MSDN Artikeln für Firebird als unsinnig. Auch Abfragen, die direkt an den Firebird Server gesendet werden, werden vom Server optimiert. Er erstellt immer einen Plan, welche Indexe er benutzt und optimiert den Zugriff. Von daher ist das wohl Microsoft spezifisch.

[alzaimar]

Es geht dabei weniger um Performance, als um Wartbarkeit und Abstraktion:

Wenn man eine DML-Operation als SP kapselt, dann ist für die Applikation die Sache erledigt. Sie sagt dem DBMS 'Speicher das Zeugs mal'. WIE die DBMS das genau macht, ist egal. Und wie es heute bzw. morgen aussieht, kann der Applikation auch egal sein. Wenn später die einfache INSERT-Anweisung in EINE Tabelle mal aufgespaltet werden soll (vielleicht will man ja einen zweiten Server verwenden oder spaltet die Tabelle in mehrere auf), dann müsste man die Applikation aufbohren. Mit einer Stored Procedure hat man die Aufgaben schön getrennt, ändert nur die Prozedur und fettich.

Vielleicht will man -schwupps- mal eben ein Logging einbauen: Kein Problem, das geht sogar im laufenden Betrieb.
Oder mal eine Konsistensprüfung: No problem...

Natürlich erfolgt der Zugriff auf die Tabellen dann auch nicht direkt, sondern grundsätzlich und ausnahmslos über Views/Functions. Auch hier hat man dann eine Möglichkeit, die Tabelle später zu trennen, erweitern oder komplett zu verändern: So lange die Applikation immer die gleiche Datenstruktur 'sieht'...

Weiterhin braucht man keine 4 Prozeduren pro Tabelle: Wir verwenden pro (logischer) Tabelle genau eine Stored Procedure mit einem Parameter 'Action', der angibt, ob man einfügen, löschen und verändern möchte. Nach dem 'Action'-Parameter folgen dann die ganzen Parameter für die Operation.

Noch konsequenter ist es, die Parameter als XML o.ä. zu übergeben, denn dann muss man daran nie wieder etwas ändern.

Wir haben mal mit einer JSON-ähnlichen Parameterübergabe experimentiert. Leider lag der Overhead, der zum extrahieren der Parameter nötig war (unoptimierte SQL-Stringoperationen) bei ca. 10-15% der Gesamtperformance und das erschien uns damals zu hoch: Heute sind wir schlauer und würden das in Kauf nehmen, denn die Wartbarkeit steigt um das 10-50 fache (wenn man das überhaupt messen kann).

Also: Ich kann das nur empfehlen, denn es bietet eine sehr elegante und saubere Möglichkeit, das Verhalten im laufenden Betrieb zu verändern.