SQL Stored procedures

[derocco]

Hi
Ich plane gerade eine App. Es geht um ein Druckerprogramm, dass verschiedene Etiketten drucken kann.

Verschiedene Filialen drucken verschiedene Layouts. (Text plus Logo)

Periodisch wird das Layout angepasst.

Mein Ansatz ist:
- Auf den Clients in den FIlialen läuft das Programm. Daten für das layout sind lokal abgelegt.
- periodisch kann ein neues layout am server abgeholt werden. (user klickt update)
- Programm verbindet sich mit meinem SQL server und holt sich da die infos für datenupdate oder auch layout.
- uberschreibt damit die lokalen daten und ist wieder ready.

Das ganze wüde ich planen mit stored procedures zu realisieren. Das hat den Vorteil, dass das Programm KEIN Embedded SQL callt, sonder immer mit zb. call procedureXXX (XXX = Filialennummer) den gleichen aufruf absetzt.

Ich kann dann das resultat zentral auf dem Server vorab anpassen.

Ich seh da keinen nachteil von stored procedures, würde aber das erste mal damit arbeiten.

Hints? Tipps? Fehler im setup?

 

[SymA]

Mach ne Schnittstelle die der Client ansprechen kann auf dem Server. Die Schnittstelle liefert geeignete Daten. Ob du Stored Procedures benutzt oder nicht ist wohl eine Vorliebe. Am Ende hast das gleiche optimierte Query nur dass sämtliche Abfragen in der Datenbank sind und du evtl. Schwierigkeiten bekommst bei Versionierung, Datenbankmigrationen etc - weil auch Definer je nach Datenbank unterschiedlich aussehen (z.B. MariaDB <-> Percona <-> MySQL).
Grundsätzlich würde ich beim Start des Client immer Daten abgleichen, sonst hast du möglicherweise inkonsistente Zustände, wenn ein Client alte Daten bearbeitet, die auf dem Server schon geändert wurden.

Edit:
Ich würde einen Client nie auf einen Remote Datenbank Server direkt verbinden lassen, ohne Credentials zu Prüfen durch eine Schicht dazwischen - am Ende hast du einen gehijackten Server stehen, oder einen gefakten Client oder versucht wirres Zeug auf der DB zu tun

 

[sdwaroc]

Dann lies dich ruhig erstmal in Stored Procedures und Functions ein. Wenn man sich dafür entscheidet kann das durchaus einen Einfluss auf das benötigte Datenbankdesign haben. Bspw. wie können Resultsets zurück gegeben werden, etc.. Wenns da keine Konflikte mit dem bisherigen Design gibts spricht nichts dagegen mit Stored Procedures zu arbeiten. Dabei must du natürlich nach wie vor auf Injections u.Ä. achten, Stored Procedures sind kein nativer Schutz dagegen.

 

[wahli]

Warum geht nicht eine normale Query/View mit der Fillialnummer in der where-Bedingung?
Oder anders rum: warum Stored Procedure?

Wie sieht es mit der Security aus?
Wie ist der Zugriff von den Filialen auf den Server abgesichert?
Greift die Filiale direkt auf die DB zu?
Darf jede Filiale die Layouts der anderen Filialen sehen?

 

[sdwaroc]

Die Frage ist doch: Warum sollte man das Interface nicht in Stored Procedures definieren?

 

[derocco]

ich möchte einfach das Resultat set nicht im Programm definieren, sondern in der DB.

Wennich nund aus dem client ein Komplexes query mit diversen joins etc absetzte ahbe ich einfach viel logik im client und gebe aufschluss über meine tabellenstruktur.

Der Client wird so sein, dass er einfach mit einem Fullset Daten umgehen kann aber wenn weniger geliefert (img. url bsp) werden, dann lässt er zB. das Image weg.

Mit Stored Procedures kannich im client einfach einen simplen call machen und das SQL selber liegt auf der DB.

Ev merke ich dann ja wenn die DB wächst, dass die Queries so nicht performen. Dann kann ich Zentral eine Anpassung machen und muss nicht ein embedded query im Programm in allen clients ändern.

Betreffend ABsicherung habe ich mirnoch nicht viel gedanken gemacht, da das nicht mein spezialgebiet ist. (Ausser die überlegung mit dem expose der tabellenstruktur, die ich mit SP verhindern kann)

Was empfielst du hier zu bedenken?

 

[wahli]

Vielleicht solltest du auf Serverseite eine Serverapplikation bereitstellen, z. B. nur für REST-Calls. Dann kannst du einmal die REST-Schnittstelle definieren, welche die Clients aufrufen. Somit kannst du die evtl. spätere Anpassungen auf Serverseite erledigen und die Datenbank ist nicht direkt übers Internet aufrufbar.

Eine Serverapplikation, die nur REST-Schnittstellen bietet, ist schnell programmiert.

Wegen Absicherung musst du halt selbst schauen. Da kommt es auch auf die Clients drauf an. Die müssen sich am Server authentifizieren können, d. h. die Authentifizierung muss von Client und Server unterstütz werden.

 

[GrafZaal]

Vielleicht solltest du auf Serverseite eine Serverapplikation bereitstellen, z. B. nur für REST-Calls. Dann kannst du einmal die REST-Schnittstelle definieren, welche die Clients aufrufen. Somit kannst du die evtl. spätere Anpassungen auf Serverseite erledigen und die Datenbank ist nicht direkt übers Internet aufrufbar.

Sofern du nicht in einem firmeninternen Netzwerk bist, solltest du echt eine Abstraktionsschicht einbauen. Zwecks Sicherheit und zwecks Modularisierung des gesamten Systems.

 

[kelox]

Ich würde keine REST/Servcer Schicht dazwischen machen. So etwas macht das System nur komplexer. Ich habe bis jetzt keinerlei Anforderungen gelesen, die diese zusätzliche Komplexität rechtfertigen würden. KEEP IT STUPID SIMPLE! Das KISS Prinzip greift hier.

Zum Thema Sicherheit:
Jede Fiale bekommt einen eigenen Nutzer im SQL Server. Dieser Nutzer hat nur Zugriff auf die Daten der Fiale. Dieser Nutzer hat natürlich sonst keine weiten Berechtigungen. Zusätzlich kann die Verbindung zum SQL Server über ein VPN abgesichert werden, so dass der SQL Server ebene nicht "im Internet" steh. Man kann den Zugriff ebenfalls Zertifikatbasiert/IP Beschränkt etc machen. Security ist acuh ein Infrastruktur "Problem"...das löst man nicht durch eine Zusätzliche Komponente, die ebenfalls wieder gewartet werden muss...bzw. die wieder neue Sicherheitsprobleme bringen kann.

Wenn dein Datenschema einfach ist, dann reicht die Stored Procedure.

 

[Tumbleweed]

Ich unterstütze wahli und GrafZaal in ihrem Vorschlag einen REST-Service zwischenzuschalten. Der Mehraufwand ist minimal, der Vorteil der Abstraktion für die Zukunft definitiv gegeben. Die Clients sollen sich nicht darum kümmern, ob da eine MySQL, eine Oracle oder gar irgendwann eine MongoDB läuft. Es gibt genug Gründe (Lizenzkosten, Performance, Skalierbarkeit,...), warum sich das im Laufe der Zeit ändern kann und dann will ich nicht in zig Filialen den Client mit einem neuen DB-Treiber updaten müssen.

Und ich unterstütze auch die Anmerkung, dass man eine Datenbank auf keinen Fall direkt ins WAN hängt. Nicht alles was technisch möglich ist, ist eine gute Idee und so etwas würde kein verantwortlicher Admin, der was auf sich hält, mitmachen.

 

[kelox]

Ich unterstütze wahli und GrafZaal in ihrem Vorschlag einen REST-Service zwischenzuschalten. Der Mehraufwand ist minimal, der Vorteil der Abstraktion für die Zukunft definitiv gegeben. Die Clients sollen sich nicht darum kümmern, ob da eine MySQL, eine Oracle oder gar irgendwann eine MongoDB läuft. Es gibt genug Gründe (Lizenzkosten, Performance, Skalierbarkeit,...), warum sich das im Laufe der Zeit ändern kann und dann will ich nicht in zig Filialen den Client mit einem neuen DB-Treiber updaten müssen.

Und ich unterstütze auch die Anmerkung, dass man eine Datenbank auf keinen Fall direkt ins WAN hängt. Nicht alles was technisch möglich ist, ist eine gute Idee und so etwas würde kein verantwortlicher Admin, der was auf sich hält, mitmachen.

Das ist genau das, worum es bei YAGNI "You aren't gonna need it" geht. Warum nur ein REST Service? Mach doch noch nen Cache und ne Volltextsuche dazu....und überhaupt, pack jede einzelne Komponente in ein Docker Container.....und hoste das dann global verteilt in AWS. Achso, ML solltest du auch noch nutzen, damit vorhergesehen werden kann, wann Vorlagen geupdatet werden müssen - Warum soll der Fialmensch da sich drum kümmern einen Button zu klicken.

Man entwickelt nicht für etwas, was mal potenziell passieren könnte. Keep it Simple....Wenn es so einfach ist einen REST Service zu machen, warum nicht dann, wenn man es wirklich erst brauch. Wenn später Anforderungen kommen, wo ein REST Service sinn macht, dann kann man ihn einführen, aber Sachen nutzen ohne das es dafür Anforderungen gibt, sorgt nur für (sinnlosen) Mehraufwand.

 

[derocco]

Ich finde den Ansatz REST auch gut. Eben eventulel will man ja mal die DB ändern darunter...

Was meinst du mit ML?

 

[kelox]

Was meinst du mit ML?

Machine Learning .....geht aber bei deinem Ansatz auch einfacher . Achso, um die DB einfach zu wechseln, reicht es wenn du in deinem Client Programm ein ORM Framework verwendest....nix anderes würde dein REST Service machen. Aber du kannst natürlich auch einen REST Service machen.

 

[Tumbleweed]

Man entwickelt nicht für etwas, was mal potenziell passieren könnte. Keep it Simple....Wenn es so einfach ist einen REST Service zu machen, warum nicht dann, wenn man es wirklich erst brauch. Wenn später Anforderungen kommen, wo ein REST Service sinn macht, dann kann man ihn einführen, aber Sachen nutzen ohne das es dafür Anforderungen gibt, sorgt nur für (sinnlosen) Mehraufwand.

Nein, da hast du KISS missverstanden bzw. überinterpretiert. Überspitzt gesagt plädierst du dafür, jegliche architektonische Grundordnung wegzulassen und eine "geht doch so"-Lösung hinzuklöppeln. Ich habe dir doch schon ein Beispiel genannt, wo du hinterher Mehraufwand hast, weil du initial eine falsche Architekturentscheidung getroffen hast. Das ist ungefähr so als wenn du sagst - Wozu MVC? Ich werde sowieso nie die Persistenzschicht oder das Frontendframework austauschen, wozu soll mein Frontend sich dann erst durch einen Controller hangeln, wenn ich auch direkt die SQL-Query abfeuern kann.

Und was jetzt an einem Cache und einer Volltextsuche so abwegig sein soll, kann ich auch nicht erkennen. Genauso wenig wie ein Deployment mit Docker, was viele Vorteile mit sich bringt.

 

[kelox]

Nein, da hast du KISS missverstanden bzw. überinterpretiert. Überspitzt gesagt plädierst du dafür, jegliche architektonische Grundordnung wegzulassen und eine "geht doch so"-Lösung hinzuklöppeln. Ich habe dir doch schon ein Beispiel genannt, wo du hinterher Mehraufwand hast, weil du initial eine falsche Architekturentscheidung getroffen hast. Das ist ungefähr so als wenn du sagst - Wozu MVC? Ich werde sowieso nie die Persistenzschicht oder das Frontendframework austauschen, wozu soll mein Frontend sich dann erst durch einen Controller hangeln, wenn ich auch direkt die SQL-Query abfeuern kann.

Und was jetzt an einem Cache und einer Volltextsuche so abwegig sein soll, kann ich auch nicht erkennen. Genauso wenig wie ein Deployment mit Docker, was viele Vorteile mit sich bringt.

Nein, ich habe es nicht falsch verstanden. Ich habe es so verstanden, der TE hat ein Programm auf dem Client...eine exe z.B.

Dieses Programm kann doch MVC implementieren, es kann Klassen haben, die kümmern sich um die View...und Controller, die die Business Logik implementieren und Model klassen. Es gibt also diese 3 logischen Schichten.
Wieso muss er die Controller Schicht jetzt physisch in einer eigenen Komponente laufen lassen? Was ist da die Anforderung? REST macht Sinn, wenn man Clients hat die nur Text austauschen können oder man so viel Load erwartet, dass man den REST Service auf mehren Nodes laufen lassen kann. Wenn das der Fall mal sein sollte, kann er seine Controller Klassen mit der Business Logik gerne um eine REST Schnittstelle erweitern und auf dem Server deployen.

MVC Client exe -> DB

View Client -> Busines Logik -> DB

Und wie schon gesagt, der Client kann ein ORM Framework verwenden wie der HTTP Service. Bei beiden könnte man einfach die DB wechseln. Und wenn Client MVC implementiert, kann man die Business Logik auch später - wenn wirklich nötig - auslagern und einen REST Service vorschalten. So muss er einen HTTP Service laufen lassen (Node, IIS, Apache, kA was er nehmen will), dieser muss gewartet und gepflegt werden.....das ist overhead.

Wie schon gesagt, ich sehe keine Anforderung, die REST rechtfertigt. Das Architekturargument hat nix mit REST zu tuhen. MVC geht auch ohne REST. Wenn er eine JS SinglePage App machen will, ok, da macht dann REST Sinn. Oder wenn er schon ein Backend in Sprache A hat und die Client Anwendung in Sprache B ist....dann auch, aber von dem, was ich hier lese...overengineering.

Ich bin ja nicht gegen REST im Allgemeinen, aber es sollten schon Anforderungen existieren die das rechtfertigen.