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

[jobo]

Zitat von Aviator:

Zitat von jobo:

Freiheiten bei Modelländerungen erhält man nicht nur durch SP, sondern auch durch die Nutzung von Views, statt (komplexen) SQL Anweisungen.

Wenn ich jetzt gezielter drüber nachdenken würde, dann würden sich bestimmt noch die ein oder anderen Abfragen finden die per View erstellt werden könnten, aber so spontan fällt mir da nicht mehr ein. Aber Views sind nicht per se aus meinem Konzept gestrichen. Da wo ich sie benutzen kann, da werde ich sie auch nutzen.

Ok, die Sache mit "Statisch" ist ja schon geklärt.
Was Du eingangs von den SP geschrieben hast, mit denen Du alles kapseln kannst, wäre dann konsequent zu Ende gedacht/gemacht, wenn alle Datenquellen aus Prinzip als View angelegt werden.

Code:

create table document (...);
create view iDocument as Select ... from document;

Wäre der erste Schritt.
Verfeinerungen, die direkt bestimmte gejointe Daten liefern, wäre der nächste.
Verstecken von Modelländerungen usw. wäre dann irgendwann später dran. Das ist sicher nicht das primäre Ziel.

[Aviator]

Zitat von jobo:

Verstecken von Modelländerungen usw. wäre dann irgendwann später dran. Das ist sicher nicht das primäre Ziel.

Das ist wohl richtig. Erst mal muss das Programm überhaupt mal funktionieren. Ich will zwar so viel wie möglich vorab schon richtig machen, aber irgendwo muss ich natürlich auch mal eine Grenze ziehen.

Habe noch so viele Baustellen wo ich Dinge in DLLs auslagern will weil die Daten auch von anderen Programmen abgerufen werden sollen. Allerdings habe ich noch nie wirklich eine DLL geschrieben und tue mich schwer, damit diverse Dinge abzubilden.

Ein einfaches Laden von Benutzern aus der Datenbank macht mir da irgendwie schon Probleme. Ein Benutzer hat ja mehrere Eigenschaften die ich normalerweise in einer Klasse zusammenfassen würde. Aber dann fängt es ja schon an, dass man nicht so einfach Objekte über die DLL Grenze hinweg austauschen kann/sollte. Also wie funktioniert es dann ...

Ist zwar ein anderes Thema, hat aber ja doch etwas mit der Abfrage von Daten aus der DB zu tun.

[jobo]

Zitat von Aviator:

Habe noch so viele Baustellen wo ich Dinge in DLLs auslagern will weil die Daten auch von anderen Programmen abgerufen werden sollen. Allerdings habe ich noch nie wirklich eine DLL geschrieben und tue mich schwer, damit diverse Dinge abzubilden.

Das wirft auch wieder ein etwas anderes Licht auf die Sache. Ich weiß nicht, ob ich heute noch mit DLL anfangen würde.

Aber das ist ein schönes Beispiel für den Einsatz von Views, finde ich. Hier geht es dann nicht um Modelländerungen, sondern um sinnvoll Einschränkungen. Ein bestimmtes Programmmodul erlaubt bspw. die Zuordnung von Verantwortlichen zu Dokumenten. Ein View liefert da nun keine anderen Felder, sondern per Definition nur die Menge der Personen, die bestimmte Sachen dürfen, via Where Clause fest eingebaut. In anderen Abteilungen liefern fast identische Views andere User für andere Module. Wenn ein Programmmodul also in der Lage ist, deklarativ mit unterschiedlichen Views zu arbeiten, kann man damit eine Menge machen und zwar zentral, ohne ständig an Prorgammcode zu fummeln.

Ich würde mir nochmal Gedanken machen, was Du alles umsetzen musst (Funktional) und wie Du es technisch einfach und flexibel erreichen kannst. Und vielleicht ist es dann doch keine SP / View Lösung, sondern irgendein JSON Datenprovider oder oder..

[Aviator]

Zitat von jobo:

Zitat von Aviator:

Habe noch so viele Baustellen wo ich Dinge in DLLs auslagern will weil die Daten auch von anderen Programmen abgerufen werden sollen. Allerdings habe ich noch nie wirklich eine DLL geschrieben und tue mich schwer, damit diverse Dinge abzubilden.

Das wirft auch wieder ein etwas anderes Licht auf die Sache. Ich weiß nicht, ob ich heute noch mit DLL anfangen würde.

Naja sagen wir mal so. DLLs werden in fast jedem Programm eingesetzt. Und die Art wie DLLs programmiert werden ist ja auch sehr einfach. Nur die Verbindung zwischen Anwendung und DLL funktioniert eben nicht so wie ich mir das wünsche. Zumindest verstehe ich es noch nicht so ganz.

Mich jetzt in noch ein anderes System einzuarbeiten würde glaube ich den Rahmen sprengen.

Zitat von sakura:

Ich weiß nicht, ob es hier bereits genannt wurde, aber zusätzlich kannst Du mittels SP auch besser Rechte vergeben - je nach Schema-Rechte kann man einen Nutzer dann beschränken, welche Daten er sehen/ändern kann. Laut BSI, sollten Nutzer gar keinen direkten Zugriff auf Daten bekommen, sondern immer mittels Views/SP bedient werden.

......

Wurde soweit ich weiß noch nicht genannt, war mir ausnahmsweise aber auch bekannt.

Nur die Berechtigungen verwalte ich über meine eigene Software.

[sakura]

Zitat von Aviator:

Nur die Berechtigungen verwalte ich über meine eigene Software.

Lässt den Nutzer aber dann immer noch mittels OSQL direkt auf die Datenbank und die Daten, wenn die DB selbst keinen Schutz eingebaut hat

......

[Aviator]

Zitat von sakura:

Zitat von Aviator:

Nur die Berechtigungen verwalte ich über meine eigene Software.

Lässt den Nutzer aber dann immer noch mittels OSQL direkt auf die Datenbank und die Daten, wenn die DB selbst keinen Schutz eingebaut hat

......

Aber dafür braucht man doch auch noch einen Benutzernamen und ein Passwort. Oder verstehe ich das falsch? Und auf dem Server sind keine Benutzer angelegt außer der Hauptbenutzer. Und das Passwort davon kennt niemand. Und es kennt sich auch niemand so gut mit Rechnern aus, als das da jemand was hacken könnte. Und selbst wenn, dann würden die sich ja ins eigene Fleisch schneiden. Also bringen tut es den Mitarbeitern nix. Die Dokumente selbst sind auch nicht in der DB abgelegt, sodass da auch keiner ohne die Software dran käme da die Dokumente verschlüsselt abgelegt werden.