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

Zitat von Papaschlumpf73 (Beitrag 1349173)

Gerade bei größeren oder größer werdenden Projekten haben m.E. die SP große Vorteile:

[...]

Super! Danke für die Infos. :thumb:

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:

Zitat von Papaschlumpf73 (Beitrag 1349194)

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. :cyclops:

[Lemmy]

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.

[Aviator]

Zitat:

Zitat von Lemmy (Beitrag 1349197)

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. :pale:

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.

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

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

[Aviator]

Zitat:

Zitat von mjustin (Beitrag 1349204)

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:

Zitat von Lemmy (Beitrag 1349205)

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 :oops: :lol:): 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:

Zitat von hoika (Beitrag 1349260)

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

Genau das ist, wie beschrieben, der Fall. :wink:

[Lemmy]

Zitat:

Zitat von Aviator (Beitrag 1349207)

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?

genau. Und hier macht es eben einen großen Unterschied ob du da mit Queries hantieren musst:

Delphi-Quellcode:

  summe := qryRechnung.FieldByName('Skonto').AsCurrency * qryPosition.FieldByName('Anzahl').AsCurrency * qryPosition.FieldByName('Einzelpreis').AsCurrency;

oder ob du Objekte zur Verfügung hast

Delphi-Quellcode:

  summe := Rechnung.Skonto * Positon.Anzahl * Position.Einzelpreis;

daher: Nimm dir ein, zwei Tage Zeit und schau dir die Thematik an.

[jobo]

Mein Senf:
SP sind nicht aus Prinzip schneller. Sie vermeiden am ehesten Datentransport zum Client. Wenn das so ist, sind sie schneller.
Arbeitet ein Client "mühsam" per Schleife, irgendwelche Updates oder sowas durch, ist es per SP schneller.
Ein reines Select per SP ist nicht schneller, es ist eigentlich genau das gleiche.

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

Das Thema Testing und Testdaten sehe ich so, dass es am besten in der DB aufgehoben ist. Gerade SP und ein paar Scripte und die Nutzung von Transaktionen (Commit/Rollback) erlauben es, extrem schnell und viel Testdaten zu generieren und Tests zu durchlaufen. Im Zweifel sogar im laufenden Betrieb (kann man sich vielleicht firmenintern erlauben, natürlich hat man normalerweise Testsysteme dafür)

SP lohnen sich m.E. vor allem dann, wenn man die Fähigkeiten der DB ausreizen will und die können recht groß sein, zb. auch bei MS SQL, wenn ich das richtig verstanden habe.
Insbesondere das Thema DMS stelle ich mir hier ganz spannend vor, weil es auf einem MS Server mit MS Dokumentensoftware (also Word und Excel und Co) ziemlich viel serverseitige Dienste erlaubt.

Ansonsten vielleicht doch eher ORM oder ein "fertiges" OpenSource System erweitern.

P.S:Wenn mal ein weiteres Clientsystem hinzukommen soll, bspw. Webportal Extranet DMS, dann sind SP natürlich sehr gut geeignet.

[Aviator]

Zitat:

Zitat von Lemmy (Beitrag 1349273)

Zitat:

Zitat von Aviator (Beitrag 1349207)

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?

genau. Und hier macht es eben einen großen Unterschied ob du da mit Queries hantieren musst:

Delphi-Quellcode:

  summe := qryRechnung.FieldByName('Skonto').AsCurrency * qryPosition.FieldByName('Anzahl').AsCurrency * qryPosition.FieldByName('Einzelpreis').AsCurrency;

oder ob du Objekte zur Verfügung hast

Delphi-Quellcode:

  summe := Rechnung.Skonto * Positon.Anzahl * Position.Einzelpreis;

daher: Nimm dir ein, zwei Tage Zeit und schau dir die Thematik an.

Hmm. Muss ich mir dann doch mal anschauen. Bisher habe ich mir immer direkt meine eigenen Klassen geschrieben und die Daten dann dort in einzeln angelegten Objekten gespeichert. Hatte den Vorteil, dass ich sehr einfach darauf zugreifen konnte.

Mit Feldern aus einer Query arbeite ich schon lange nicht mehr. Viel zu Umständlich. Eine Klasse hat eben zusätzlich noch die nette Eigenschaft, dass ich eine Funktion aufrufen kann, die die Daten direkt aufbereitet so wie ich sie benötige.

Zitat:

Zitat von jobo (Beitrag 1349284)

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

Bei Views habe ich eben das Problem, dass ich keine Filter von außen mitgeben kann. Eine View ist ja soweit ich weiß statisch. Bei einer SP kann ich noch Parameter angeben welche dann in einer WHERE Klausel verarbeitet werden können. Bei meinem DMS wüsste ich nicht, welche Daten ich ohne Filter einfach so selektieren kann. Außer eventuell alle angelegten Benutzer um auf einem LoginScreen diese in einer Combobox anzeigen zu lassen.

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.

Zitat:

Zitat von jobo (Beitrag 1349284)

Das Thema Testing und Testdaten sehe ich so, dass es am besten in der DB aufgehoben ist. Gerade SP und ein paar Scripte und die Nutzung von Transaktionen (Commit/Rollback) erlauben es, extrem schnell und viel Testdaten zu generieren und Tests zu durchlaufen. Im Zweifel sogar im laufenden Betrieb (kann man sich vielleicht firmenintern erlauben, natürlich hat man normalerweise Testsysteme dafür)

SP lohnen sich m.E. vor allem dann, wenn man die Fähigkeiten der DB ausreizen will und die können recht groß sein, zb. auch bei MS SQL, wenn ich das richtig verstanden habe.
Insbesondere das Thema DMS stelle ich mir hier ganz spannend vor, weil es auf einem MS Server mit MS Dokumentensoftware (also Word und Excel und Co) ziemlich viel serverseitige Dienste erlaubt.

Ansonsten vielleicht doch eher ORM oder ein "fertiges" OpenSource System erweitern.

P.S:Wenn mal ein weiteres Clientsystem hinzukommen soll, bspw. Webportal Extranet DMS, dann sind SP natürlich sehr gut geeignet.

Mit MSSQL liegst du richtig. Siehe meinen Ausgangspost. :-D

An ein Webportal ist aktuell noch nicht zu denken. In unserer Firma arbeiten 100% der Benutzer an einem Windows PC. Mit Tablets oder Smartphones á la BYOD haben wir hier noch nix am Hut. Rein aus sicherheitstechnischen Gründen.

Ich muss aber zugeben das ich bereits daran gedacht habe, irgendwann mal eine App zu entwickeln um ebenfalls darauf zuzugreifen. Da ich die Anwendung aus diversen Gründen mit der VCL entwickele, müsste da sowieso ein separates Projekt werden. Somit hat das dann auch noch Zeit. :stupid:

[nahpets]

Wiese ist ein View statisch?

Nehmen wir an:

SQL-Code:

create view Koeln as select * from Kunden where ort = 'Köln'

Dann kannst du doch darauf eine Abfrage machen:

SQL-Code:

select * from Koeln as select * from Kunden where name = 'Müller'

Ein View ist doch nichts weiter, als ein in der Datenbank abgelegtes, mehr oder weniger komplexes SQL-Statement zur Abfrage von Daten, das immer wieder benutzt werden kann.

Flappsig formuliert ist für mich ein View nix weiter, als ein Shortcut auf ein in der Datenbank abgelegtes Selectstatement.

Bei einer Abfrage der View wird letztlich dieses SQL ausgeführt und die entsprechende Ergebnismenge geliefert.

Wenn Du willst kannst Du auch per SQL mehrere View joinen ...

Zum eher Grundsätzlichen:

Bei einem leistungsstarken Datenbanksystem halte ich die Nutzung von SPs ... für deutlich effektiver. Gerade bei großen Datenmengen (zigtausende oder Millionen von Datensätzen) müssen diese nicht zum Client und verändert wieder zurück. Änderungen kann man per Trigger protokollieren ...

Ebenso Logiken, die bei der Einfügung neuer Datensätze in die Datenbank, ausgeführt werden müssen. (Ebenso natürlich auch beim Update oder Delete.)

Meine praktische Erfahrung aus der Vergangenheit unter C++ und Oracle ist die: Je mehr Logik in der Datenbank implementiert war, um so schneller liefen die Jobs ab.
Es ging hierbei um Datenmengen von 100ten Millionen Datensätzen in 'nem recht komplexen Datenmodell.
Die Zeitersparnis lag da im Bereich von Stunden und ab und an auch mal ein paar Tagen.

Meine persönliche Regel ist: Alles was die Datenbank machen kann, macht die Datenbank.
Außerhalb der Datenbank wird nur das erledigt, was mit Mitteln der Datenbank nicht umzusetzen ist.

So gerne ich mit Delphi programmiere. Das Delphiprogramm übernimmt nur die Teile, die die Datenbank nicht erledigen kann. Ggfls. per Benutzeroberfläche den Anstoß der SPs ..., um bestimmte Aufgaben zum von Benutzer manuell bestimmten Zeitpunkt auszuführen ...

Regelmäßig auszuführende Aufgaben, die die Datenbank selbständig ausführen kann, werden mit der datenbankeigenen "Prozesssteuerung" geplant und überwacht.

[Aviator]

Zitat:

Zitat von nahpets (Beitrag 1349301)

Wiese ist ein View statisch?

Sorry, da hatte ich etwas falsch im Kopf. Man kann ja auch noch einem SELECT von einer View eine Where Klausel mitgeben. :oops:

Zitat:

Zitat von nahpets (Beitrag 1349301)

Meine persönliche Regel ist: Alles was die Datenbank machen kann, macht die Datenbank.
Außerhalb der Datenbank wird nur das erledigt, was mit Mitteln der Datenbank nicht umzusetzen ist.

So gerne ich mit Delphi programmiere. Das Delphiprogramm übernimmt nur die Teile, die die Datenbank nicht erledigen kann. Ggfls. per Benutzeroberfläche den Anstoß der SPs ..., um bestimmte Aufgaben zum von Benutzer manuell bestimmten Zeitpunkt auszuführen ...

Regelmäßig auszuführende Aufgaben, die die Datenbank selbständig ausführen kann, werden mit der datenbankeigenen "Prozesssteuerung" geplant und überwacht.

Klingt interessant. Da müsste ich nur schauen, was ich mit Triggern machen könnte. So tief bin ich dann doch nicht mit dem SQL-Server vertraut. Ich habe zwar bisher alles gelöst bekommen, aber (für mich) extreme Aufgabenstellungen wie Trigger, Jobs (wird bei mir nicht benötigt), usw. habe ich bisher nie umgesetzt bzw. benötigt.

[jobo]

Zitat:

Zitat von Aviator (Beitrag 1349295)

Zitat:

Zitat von jobo (Beitrag 1349284)

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:

Zitat von jobo (Beitrag 1349335)

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:

Zitat von Aviator (Beitrag 1349345)

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

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

...:cat:...

[Aviator]

Zitat:

Zitat von jobo (Beitrag 1349351)

Zitat:

Zitat von Aviator (Beitrag 1349345)

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:

Zitat von sakura (Beitrag 1349355)

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.

...:cat:...

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

Nur die Berechtigungen verwalte ich über meine eigene Software. :cyclops:

[sakura]

Zitat:

Zitat von Aviator (Beitrag 1349357)

Nur die Berechtigungen verwalte ich über meine eigene Software. :cyclops:

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 ;)

...:cat:...

[Aviator]

Zitat:

Zitat von sakura (Beitrag 1349358)

Zitat:

Zitat von Aviator (Beitrag 1349357)

Nur die Berechtigungen verwalte ich über meine eigene Software. :cyclops:

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 ;)

...:cat:...

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.