AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi [SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage

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

Offene Frage von "Aviator"
Ein Thema von Aviator · begonnen am 29. Sep 2016 · letzter Beitrag vom 30. Sep 2016
Antwort Antwort
Seite 1 von 3  1 23   
Aviator

Registriert seit: 3. Jun 2010
1.610 Beiträge
 
Delphi 10.3 Rio
 
#1

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

  Alt 29. Sep 2016, 12:18
Datenbank: MSSQL • Version: 2008 u. höher • Zugriff über: ADO
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.
  Mit Zitat antworten Zitat
Papaschlumpf73

Registriert seit: 3. Mär 2014
Ort: Berlin
308 Beiträge
 
Delphi 12 Athens
 
#2

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

  Alt 29. Sep 2016, 13:03
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.
  Mit Zitat antworten Zitat
Aviator

Registriert seit: 3. Jun 2010
1.610 Beiträge
 
Delphi 10.3 Rio
 
#3

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

  Alt 29. Sep 2016, 13:16
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
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.851 Beiträge
 
Delphi 11 Alexandria
 
#4

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

  Alt 29. Sep 2016, 13:37
Es gibt auch Tools, mit denen man SPs debuggen kann.
Markus Kinzler
  Mit Zitat antworten Zitat
Papaschlumpf73

Registriert seit: 3. Mär 2014
Ort: Berlin
308 Beiträge
 
Delphi 12 Athens
 
#5

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

  Alt 29. Sep 2016, 13:57
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.
  Mit Zitat antworten Zitat
Aviator

Registriert seit: 3. Jun 2010
1.610 Beiträge
 
Delphi 10.3 Rio
 
#6

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

  Alt 29. Sep 2016, 14:05
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.
  Mit Zitat antworten Zitat
Lemmy

Registriert seit: 8. Jun 2002
Ort: Berglen
2.364 Beiträge
 
Delphi 10.3 Rio
 
#7

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

  Alt 29. Sep 2016, 14:15
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.
  Mit Zitat antworten Zitat
Aviator

Registriert seit: 3. Jun 2010
1.610 Beiträge
 
Delphi 10.3 Rio
 
#8

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

  Alt 29. Sep 2016, 14:29
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.
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
3.003 Beiträge
 
Delphi 2009 Professional
 
#9

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

  Alt 29. Sep 2016, 14:53
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.
Michael Justin
  Mit Zitat antworten Zitat
Lemmy

Registriert seit: 8. Jun 2002
Ort: Berglen
2.364 Beiträge
 
Delphi 10.3 Rio
 
#10

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

  Alt 29. Sep 2016, 14:53
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...
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 3  1 23   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:50 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz