Hallo zusammen,


ich weiß nicht ob ich hier richtig bin, wenn nicht dann bitte verschieben

bei uns in der Abteilung ist ein kleiner Streit entstanden mit folgendem Hintergrund:

wir haben einen Webservice der von verschiedenen Schnittstellen mit Daten versorgt wird, diese in einer Datenbank speichert und natürlich an eine GUI weitergibt.
Nun haben wie in der Abteilung einige Entwickler sitzten, die haben vor einiger Zeit diesen Webservice entwickelt. Dazu haben Sie ursprünglich alle SQL-Abfragen fest in das Programm hinterlegt nun wurde das Programm immer wieder erweitert, Abfragen mussten geändert werden, sogar die Tabellen wurden schon einige Male geändert. Dabei kam die Idee auf, alle SQL-Befehle in der Datenbank selber zu hinterlegen um diese schneller ändern zu können.

Nun würde im Programm nur noch eine SQL-Anweisung vorhanden sein und diese würde dann immer die entsprechenden SQLs aus der DB-Tabelle holen. Die Meinung meiner Kollegen wird dadruch gestützt das in der Software KHK(ERP-Software), ebenfalls die SQL-Anweisungen in der DB stehen würden und da die Zugriffszeiten sehr schnell sind. Ich kenne das KHK nicht und kann mir da keine Meinung dazu bilden.

Ich würde weiterhin die SQL-Anweisung im Code hinterlegen (Resssourcen-Datei o.ä.), da ich denke das durch den doppelten Zugriff auf die Datenbank ein erheblicher Geschwindkeitsverlust da sein würde. Teilweise sind in einer Webmethode 10 -15 Zugriffe auf die Datennbank, das würde bedeuten ich würde doppelt soviele Zugriffe erzeugen, wie in meiner vorgeschlagenen Version.

was haltet Ihr davon

Hallo,

die Geschwindigkeit sollte normalerweise keine Rolle spielen:
* Wenn die "echten" SQL-Befehle direkt aus dem Programm kommen, ist es ein Zugriff vom Programm auf die DB, dann die Ausführung innerhalb der DB, dann die Rückgabe des Ergebnisses an die UI.
* Wenn die Anwendung einen "Verteilerbefehl" an die DB schickt, ist es ein Zugriff vom Programm auf die DB, dann ein weiterer Befehl innerhalb der DB, dann die Ausführung innerhalb der DB, dann die Rückgabe des Ergebnisses an die UI.
Der Unterschied liegt also nur in der Verteilung eines einzelnen Befehls innerhalb der DB, und das ist nicht zu spüren.

Wenn es sich bei einer Webmethode "um 10 bis 15 Zugriffe" handelt, würde das allerdings bedeuten:
* Wenn die "echten" SQL-Befehle direkt aus dem Programm kommen, sind es 10 Zugriffe vom Programm auf die DB, jeweils die Ausführung innerhalb der DB, dann die Rückgabe von 10 Ergebnissen an die UI.
* Wenn die Anwendung einen "Sammelbefehl" an die DB schickt, ist es ein Zugriff vom Programm auf die DB, dann 10 weitere Befehle innerhalb der DB, jeweils die Ausführung innerhalb der DB, dann die Rückgabe eines Ergebnisses an die UI.
Das würde bedeuten: Die Sammelbefehle sparen deutlich DB-Zugriffe ein.

Dennoch halte ich (auch nach euren Erfahrungen) die Wartbarkeit am wichtigsten, und das spricht für die Sammlung aller variablen Daten an einer Stelle. Wenn alle möglichen SQL-Befehle als SPs oder Views in der DB gesammelt werden (wie es nach den Möglichkeiten einer DB sinnvoll wäre), bliebe dennoch die Schnittstelle für die verschiedenen Möglichkeiten im Programm - und das wären faktisch gleich viele einzelne Aufrufe. Deshalb tendiere ich zur Empfehlung: Macht eine Assembly, die den ganzen Zugriff kapselt, und sammelt die SQL-Befehle dort in einer Ressourcen-Datei.

Gruß Jürgen

PS. Ich glaube, das Problem hat überwiegend mit DB zu tun und weniger mit Web. Deshalb sollte es das richtige Unterforum sein.

Hallo,

das Problem ist aber das wir eben nicht 1 Befehl an die DB schicken und das dann in der DB die ganzen SQL-Befehle/Views/Procedure ausgeführt werden. Sondern der Webservice holt z.b. Userdaten aus der Datenbank diese werden dann verifiziert, dann entsprechend irgendwelche Config-Daten und dann irgendwelche Druckdaten, es werden Historydaten gespeichert und so weiter. Auf alle Fälle ist der Datenfluss i.d.R. WS=>DB=>WS=>SS=>WS=>DB=>WS.........

Da wir mit vielen Schnittstellen(SAP, Waagen usw.) arbeiten müssen ist halt ein sehr häufiger Datenbankzugriff nötig

Nun würde das im Falle meines Kollegens der Datenfluß folgendermaßen aussehen:

WS=>DB(SQL-Befehl holen) => WS(evtl. where Anweisung füllen)=>DB(SQL-Befehl ausführen)=>WS=>SS=>WS.......


Erklärung:
WS => Webservice
SS => Schnittstelle
DB => Datenbank

Einfach nur wow . Die Idee, SQL-Queries als Daten in der DB zu speichern, ist wirklich sowas von verquer, dass deine Kollegen das eindeutig von TDWTF geklaut haben müssen . Seriously, darauf kann man doch nur kommen, wenn man noch nie etwas von Stored Procedures/Views gehört hat - oder übersehe ich da irgendeinen Vorteil, der sich mir sowieso nicht erschließen wird? Und wo ist eigentlich die Query gespeichert, die die jeweilige Query lädt ?

So, das musste jetzt sein . Die wichtigste Frage bleibt doch: Was versprechen sie sich davon?
Den Punkt Geschwindigkeit hast du schon angesprochen: Während gewöhnliche Ad-Hoc-Queries und SPs sich nicht viel nehmen, erzeugt der Ansatz auf jeden Fall unnötige Zugriffe, für diese Erkenntnis muss man nicht einmal den Profiler anwerfen.
Also Wartbarkeit? Ich sehe da wirklich keinen Unterschied zwischen einer DB und einer Ressourcen-Datei, besonders wenn es um ein einziges Projekt geht. Bei mehreren würde sich, wie schon von Jürgen erwähnt, anbieten, den DAL in ein eigenes Projekt auszulagern. Ich hoffe, besagte Kollegen sind mit den drei Buchstaben nicht überfordert .

Zitat:

... oder übersehe ich da irgendeinen Vorteil, der sich mir sowieso nicht erschließen wird? ...

nun die Frage stelle ich mir ebenfalls die ganze Zeit und
wollte halt mal diese Frage an euch stellen um eventuelle Vorteile aufzuzeigen die ich nicht sehe

PS: TDWTF kannte ich noch nicht ist ja echt super

Den einzigen Vorteil, den ich erkennen kann, ist die Programm-Pflege.

Sollte eine Änderung der SQL-Befehle erforderlich sein (DB-Änderungen, Fehler im Befehl u.ä.), so muss man nur die Befehle in der entsprechenden Tabelle anpassen. Ein Korrektur am Client und die entsprechende Sofware-Verteilung entfällt dadurch oder wird zumindest reduziert.

Wie groß der Vorteil aber tatsächlich ist, kann ich nicht beurteilen, da ich bisher noch nicht auf die Idee gekommen bin, die Befehle in der DB zu speichern. Stored-Procedures, Packages, Views, etc. nutze ich aber auch sehr intensiv.

jasocul hat folgendes geschrieben :

Ein Korrektur am Client und die entsprechende Sofware-Verteilung entfällt dadurch oder wird zumindest reduziert.

Und mit SPs ist das nicht möglich ?

vielen Dank für eure Meinungen und Hinweise, auf lange Sicht werde ich Jürgens Rat in die Tat umsetzen und den gesamten Zugriff in in einen Assembly unterbringen. Momentan sind und werden die Zugriffe auf die DB, in den Ressourcendateien hinterlegt weil die Planung und Umsetzung zeitlich mom. nicht drin ist.

Glücklicherweise befinden wir uns noch in der Brainstorming-Phase so das da noch nichts in die falsche Richtung gelaufen ist.

Kha hat folgendes geschrieben :

jasocul hat folgendes geschrieben : Ein Korrektur am Client und die entsprechende Sofware-Verteilung entfällt dadurch oder wird zumindest reduziert. Und mit SPs ist das nicht möglich ?

Man kann mit Stored-Procedures Software auf den Clients verteilen? Coool. Zeig mir mal, wie das geht.

So eingesetzt verständlicher ?

Zitat:

Und mit SPs ist es nicht möglich, dass eine Korrektur am Client und die entsprechende Sofware-Verteilung entfällt oder zumindest reduziert wird?

Ja.