[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.

[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.

[Aviator]

Zitat von 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.

Interessanter Ansatz. Für solche Fälle haben wir aktuell allerdings immer eine zweite Datenbank angelegt auf der programmiert und getestet wird und dann eine Datenbank in der Realdaten stehen. Je nach Einstellungsdatei oder Compilerschalter wird dann entweder auf die Testdatenbank oder auf die echte Datenbank zugegriffen. Eine doppelte Pflege der Datenbank ist das dann auch nicht unbedingt. Bei Tests kann immer eine aktuelle Sicherung der echten Datenbank auf die Testdatenbank zurückgesichert werden. Bei Änderungen der DB werden diese erst getestet und dann in die Hauptdatenbank übernommen.

Fand ich bisher immer die einfachste Möglichkeit. Ich wollte zwar auch schon den Zugriff auf die Datenbank speziell kapseln, aber weiß noch nicht genau wie das funktionieren soll. Interfaces wären da ja sicherlich das Mittel zum Zweck.

Zitat von 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...

Also es wird eine auf unsere Firma zugeschnittene Dokumentenverwaltung [DMS]. Aktuell habe ich 17 Tabellen in denen diverse Infos stehen. Die Wahrscheinlichkeit das da noch welche dazu kommen ist sehr hoch. Aktuell bin ich immer noch so halb in der Planphase, habe aber bereits schon angefangen die ein oder andere DLL zu schreiben, weshalb ich auf diese Frage gekommen bin.

Tabellen die auf jeden Fall noch dazu kommen sind welche zum Protokollieren der Änderungen von Berechtigungen, Dokumenten, Schlagwörtern, ... (da habe ich aktuell auch noch nicht die ultimative Lösung wie ich das ohne extrem viel Aufwand protokollieren könnte).

Die Software wird bestimmt noch in den nächsten Jahren (wenn sie denn mal funktioniert) erweitert. Es wird kein Produkt das verkauft werden soll (zumindest aktuell nicht und ich denke, dass sich das auch nicht ändern wird). Die Software wird ausschließlich in unserer Firma verwendet.

CRUD (musste erstmal nachschauen was das bedeutet ): Ja, also es stehen Daten in der Datenbank die abgerufen und entsprechend angezeigt werden. Ein Berechtigungssystem ähnlich wie bei NTFS soll auch enthalten sein. Hierzu hatte ich auch mal einen Thread eröffnet wie man das am Besten umsetzt. Habe aber mittlerweile denke ich die Lösung welche ich in dem Thread auch schon vorgestellt hatte.

Was genau meinst du mit Berechnungen und Abhängigkeiten? Sowas wird ja dann normalerweise auf Programmebene und nicht in der Datenbank gemacht. Oder verstehe ich da jetzt etwas grundlegend falsch?


Gruß Aviator

[hoika]

Hallo,
ich würde keine SPs nehmen.
Wenn du eine Änderung an den Parametern machst,
sind das immer 2 Stellen zu ändern.
Dann ändert sich vielleicht die Datenstruktur
und du fässt mehrere SPs an.

Die Frage ist hier, wie viele Kunden werden das Programm benutzen,
das ergibt einen unschönen Update-Vorgang.

Solange das Programm nur in der eigenen Firma genutzt wird,
spricht nichts gegen die SPs.

[Aviator]

Zitat von hoika:

Solange das Programm nur in der eigenen Firma genutzt wird,
spricht nichts gegen die SPs.

Genau das ist, wie beschrieben, der Fall.