Gespeicherte Prozeduren

[Corey]

Hallo!

Ich entwickel mit dem Visual Studio 2005 und soll nun für ein neues Projekt auf den SQL Server 2005 umsteigen. Nun bin ich am überlegen, ob und wie viel ich an Code in die DB auslagere. Würdet ihr komplett auf "Gespeicherte Prozeduren" setzen oder alles im eigentlichen Programmcode belassen? Was habt ihr bis jetzt so an Erfahrungen damit gemacht?

Vielen Dank schonmal im Voraus!

MfG
Corey

 

[Huschi]

Hallo Corey,

es kommt ganz auf das Projekt und den Umfang der DB an. So einfach läßt sich das nicht sagen.
Einfache Beispiele:
a) Ist es ein Projekt welches viele Installationen auf unterschiedlichen DB's hat, aber die DB-Struktur keine wesentlichen Anforderungen hat, dann wäre es einfacher den SQL-Code im Programm zu halten.

b) Das Projekt hat viele User, aber nur eine zentrale DB. Die Updates/Inserts können daher zeitkritisch werden und brauchen evtl. auch ein Rollback. Dann macht es Sinn möglichst viele Transactions zu nutzen.

huschi.

 

[elias5000]

Transactions != Stored Procedures

Ob und wie viel Code man in Stored Procedures auslagert, kommt ganz darauf an, was dieser Code macht.
Müssen z.B. mit Inserts oder Updates einer Tabelle Inhalte einer weiteren Tabelle (z.B. mit Wortstämmen für Indizierung o.Ä.) mitgezogen werden, sieht das nach Stored Procedures aus, die diese Änderungen über Trigger gesteuert und für die Applikation völlig transparent durchführen.

Code, der Datenintegrität sicherstellen soll (über Fremdschlüsselbeziehungen hinaus) gehört definitiv in die DB.
Oder komplexe Suchen, die man der Applikation gerne mit einem "search(what)" zugänglich machen will.

Sowas sind Kandidaten für Stored Procedures. Normale Einfügeoperationen oder Selects eher nicht. Auch keine zusammenhängenden Einfügeoperationen (relationale Daten) - für diese reicht i.d.R. eine Transaktion um die zusammenhängenden Einfügeoperationen herum.

In die DB gehört also eigentlich alles, was nur Daten bearbeitet aber keine Funktionen der Applikation betrifft. Wenn Daten aus der Applikation in die DB gelangen oder umgekehrt, dann gehört das in die Applikation.
Datenbankinterne Datenschiebereien, die begleitend zu einem Datentransfer mit der Applikation auftreten sind dabei dem ersten Typ zuzuordnen.