[SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage

[Aviator]

Hallo zusammen,

ich bin gerade dabei ein neues Projekt zu beginnen und will dann so viel wie möglich direkt zu Beginn schon richtig machen um nicht nachher wieder alles über den Haufen werfen zu müssen.

Aktuell stehe ich vor der Frage, was denn sinnvoller und/oder sicherer ist. Ist es besser, jegliche Kommunikation (also Select, Insert, Delete, ...) über eine Stored Procedure respektive einer Funktion zu machen oder reicht es, alle Datenbankinteraktionen direkt auszuführen? Sprich ADOQuery auf die Form geklatscht, SQL.Text setzen (INSERT INTO XYZ) und feuer?

Vorteil einer SP usw. wäre ja, dass ich theoretisch die Feldnamen in einer Tabelle umschreiben kann und dann nur die entsprechende(n) Procedure(n) aktualisieren müsste. Das Programm würde unberührt bleiben. Einen Nachteil kann ich jetzt nicht direkt erkennen.

Auf der Gegenseite (was ja dann eigentlich Nachteile sind) hätte ich allerdings das Problem, dass meine Abfragen zur Laufzeit oder auch beim Debugging recht undurchsichtig sind da ich nicht weiß, was die Procedure genau ausführt.

Für das Arbeiten im Team wäre eine SP sicherlich der bessere Weg (so meine Vorstellung). In dem konkreten Fall arbeite ich aber alleine (auch wenn es ein größeres Projekt wird).

Wäre super wenn mich jemand (gerne auch viele) aufklären könnten was denn jetzt im Allgemeinen der bessere Weg wäre. Habe zu dem Thema nicht wirklich etwas im Netz gefunden, eventuell aber auch nur die falschen Schlagwörter benutzt.

[Papaschlumpf73]

Gerade bei größeren oder größer werdenden Projekten haben m.E. die SP große Vorteile:

1. Schnellere Ausführung auf dem SQL-Server; deine ADO-Query-Skripte müssen immer erst vom Server analysiert werden.

2. Bei SP mit Parameter kannst du SQL-Injection vorbeugen.

3. Man hat alle SP an einer Stelle; für deine Software-Updates kannst Du eine Textdatei als Ressource einbinden mit lauter ALTER PROCEDURE...

4. Wenn Datenbanken größer werden, müssen sie meistens auch etwas umstrukturiert werden. Man denkt ja zunächst gar nicht, was sich Kunden alles einfallen lassen. In der Textdatei mit all deinen SP kannst du dann leicht nach geänderten Tabellen- oder Feldnamen suchen, auf dem SQL-Server aktualisieren/testen und anschließend in der Update-Textdatei ersetzen. In der SQL-Eigenschaft einer ADOQuery findet nicht mal die IDE-Suche von Delphi irgend etwas.

[Aviator]

Zitat von Papaschlumpf73:

Gerade bei größeren oder größer werdenden Projekten haben m.E. die SP große Vorteile:

[...]

Super! Danke für die Infos.

Gibt es auch Nachteile von SPs? Also was ich meinte, dass beim Debugging die Übersicht evtl. verloren geht? Man muss ja dann immer auf dem Server die Procedure öffnen und schauen was die macht. Oder geht das irgendwie einfacher?

Ich werde wohl bei dem Programm dann damit beginnen, dass ich alles mit SPs, Functions und Views aufziehen werde und dementsprechend immer nur noch damit arbeite. Spricht ja dann nix dagegen, oder

[mkinzler]

Es gibt auch Tools, mit denen man SPs debuggen kann.

[Papaschlumpf73]

Habe zwar noch nie mit einem Debugger gearbeitet, jedoch dürfte der weder die SQL-Eigenschaft einer ADOQuery noch eine SP debuggen können. Egal ob ADOQuery oder ADOStoredProc müsste der Debugger wohl beim Öffnen/Ausführen mit .Open oder .ExecProc oder Active:=true oder was auch immer anhalten und kann nur den Fehler ausspucken, den der SQL-Server zurück gegeben hat.

[Aviator]

Zitat von Papaschlumpf73:

Habe zwar noch nie mit einem Debugger gearbeitet, jedoch dürfte der weder die SQL-Eigenschaft einer ADOQuery noch eine SP debuggen können. Egal ob ADOQuery oder ADOStoredProc müsste der Debugger wohl beim Öffnen/Ausführen mit .Open oder .ExecProc oder Active:=true oder was auch immer anhalten und kann nur den Fehler ausspucken, den der SQL-Server zurück gegeben hat.

Ja das ist klar. Eine SP oder Function würde ich dann ja direkt mit dem Management Studio debuggen. Nur finde ich es oft schöner, wenn man direkt sieht was denn das Statement (in dem Fall dann die SP/Function) eigentlich macht.

Aber das ist nur eine Nebensache.

Das Fazit das ich aktuell daraus schließen würde wäre, dass SPs, Views und Functions besser sind als Statements direkt an den Server zu senden.

Falls noch jemand ein gegenteiliges Argument hat, dann nur her damit.

[Lemmy]

Pack dein Businessmodell in ein OPF/ORM dann kannst Du darüber schon recht viel (eigentlich alles) der Businesslogik kapseln. Dann würde ich nur noch laufzeitkritische Dinge (wenn sie denn in der DB schneller sind) in eine StoredProcedure verpacken, das würde dann später auch den Austausch der Datenbank erleichtern.

[Aviator]

Zitat von Lemmy:

Pack dein Businessmodell in ein OPF/ORM dann kannst Du darüber schon recht viel (eigentlich alles) der Businesslogik kapseln. Dann würde ich nur noch laufzeitkritische Dinge (wenn sie denn in der DB schneller sind) in eine StoredProcedure verpacken, das würde dann später auch den Austausch der Datenbank erleichtern.

Oh je. Das ist ein ganz neues Themengebiet für mich. Habe zwar schonmal davon gelesen, aber noch nie damit gearbeitet. Wie genau das funktionieren soll weiß ich demzufolge natürlich auch nicht.

Es wird zwar mit sehr hoher Wahrscheinlichkeit nicht passieren, dass das Datenbanksystem ausgetauscht wird, aber interessieren würde mich der Ansatz schon. Ich weiß nur leider nicht, ob es meine Zeit zulässt, dass ich mich da auch noch einarbeite.

Ich will zwar versuchen meine Anwendung in kleine Teile/Module zu zerlegen, aber dafür habe ich leider zu wenig Ahnung wie das funktionieren soll. Aktuell bin ich dran, diverse Parts meine Anwendung in DLLs auszulagern da auf meine Anwendung (bzw. eher die Daten die sie speichert) auch aus einer anderen Anwendung zugegriffen werden soll. Ob das so funktioniert wie ich es mir vorstelle weiß ich leider noch nicht. Stehe ganz am Anfang der Entwicklung. Habe die letzten zwei Wochen damit verbracht, mir ein Konzept zu überlegen, wie ich das alles splitten kann. Hoffe ich habe nichts - oder wenn, dann nur einen Teil der keine großen Auswirkungen auf das ganze System hat - vergessen.

[mjustin]

Komplexere SPs sind meist auch schwerer zu testen als Code, der die Geschäftslogik clientseitig (in Delphi) realisiert: wenn man viele verschiedene Testfälle abarbeiten will, muss man die Daten in der Datenbank erst 'passend' bereitstellen, d.h. Tabellen leeren und mit Testdaten füllen.

Wenn komplexe Geschäftslogik auf der Clientseite in Delphi implementiert ist, wird im Idealfall der Test komplett ohne Datenbankverbindung durchgeführt. Er ist wesentlich schneller, so dass man bei Änderungen an der Logik auch viel schneller erkennt, ob es zu Fehlern gekommen ist.

[Lemmy]

wie groß wird denn die Anwendung? sind da 2 Tabellen dabei oder wird das einen entsprechenden Umfang annehmen? Wie ist die BUsinesslogik? Einfachste CRUD (wie bei einer ToDo-APp) oder müssen auch konkrete Anforderungen erfüllt werden (Berechnungen, Abhängigkeiten,...)

Nimm dir die Zeit und schau dir mal ein, zwei OPF an, auch wenn es schwer ist, schau dir tiopf an, ggf. auch kommerzielle Systeme (TMS, Devart). Ja, das ist ein verdammt schwerer Einstieg, wenn Du aber in ein paar Jahren die Software immer noch pflegen musst, lohnt sich das meiner Meinung nach...