VB oder SP

[MartinHan]

Hallo,

meine Anwendung für die Schule läuft, Frontend Acces, backend Ms Sql.
Ich bin jetzt in der Optimierungsphase.

Ich kann jetzt natürlich bis ans Ende meiner Tage daran basteln und Dinge optimieren.
Eine Funktion habe ich jetzt ausprobiert:

Aufgabe: Hinzufügen eines Umsatzes zur Tabelle Umsatz

Das geht natürlich mit Vb Funtionen .addew---etc. .
Man kann aber auch eine Stored Procedure in der DB aufrufen.
Beides klappt.
Aber was ist die bessere Variante?

Nach der reinen Lehre ist es wahrscheinlich besser, alle DB-spezifischen Funktionen in die Db zu verfrachten. und dann nur noch die SP quasi als API aufzurufen.

Gibt es Meinungen dazu ?

Frohes Fest und danke für die Hilfe!

Martin

[MzKlMu]

Hallo,

Aufgabe: Hinzufügen eines Umsatzes zur Tabelle Umsatz
Das geht natürlich mit Vb Funtionen .addew---etc. .

Ohne nähere Infos würde mir da als erstes ein gebundenes Formular einfallen. Da braucht es weder VB (nicht eher VBA ?) noch SP.
Und bestechend einfach ist es auch.

[PhilS]

Aufgabe: Hinzufügen eines Umsatzes zur Tabelle Umsatz

Das geht natürlich mit Vb Funtionen .addew---etc. .
Man kann aber auch eine Stored Procedure in der DB aufrufen.
Beides klappt.
Aber was ist die bessere Variante?

Generell "Besser" ist i.d.R. schon eine Stored Procedure zu verwenden, weil man damit ein weiteres Abstraktionslayer zwischen den Datenstrukturen und der (Frontend-)Anwendung schafft. Damit macht man beiden die beiden Teile unabhängiger voneinander, da man die SP für Änderungen auf der einen oder anderen Seite anpassen kann und damit die jeweils andere Seite von einer solchen Änderung gar nichts mitbekommt. - Die Frage ist, ob das allein schon den Aufwand lohnt.

Konkret besser ist die SP, wenn man mehrschrittige Operationen hat. D.h. wenn du in einer Operation gleich mehrere Datensätze hinzufügen oder ändern möchtest. Dann lässt sich das in einer SP alles wesentlich zuverlässiger in einer Transaktion kapseln und somit zu einer atomaren Operation zusammenfassen.
Ein weiteres konkretes Argument für die SP wäre ein Berechtigungskonzept, das dem Benutzer gar nicht erlaubt einfach "freihändig" Daten in Tabellen zu schreiben, sondern nur durch den definierten Ablauf einer SP.

Für deinen Beispielfall sehe ich hier erstmal keinen Grund eine SP zu verwenden, der den zusätzlichen Aufwand rechtfertigt.

[Bitsqueezer]

Hallo Martin,

das kann man nicht allgemeingültig beantworten, hängt immer vom Fall ab.
Ja, es kann sinnvoll sein, alle Operationen, die die Datenbank betreffen, im Backend zu handhaben. Das erlaubt auch, Zugriffe genau mit Rechten zu regeln, was je nachdem ein sehr wichtiger Punkt ist, besonders, wenn es um personenbezogene Daten geht, was man bei einer Anwendung für die Schule annehmen könnte.

Auf der anderen Seite muß man sich überlegen, wo genau man die Grenze ziehen will und wieviel Aufwand man bereit ist, zu betreiben. Ein gebundenes Access-Formular etwa ist darauf angewiesen, alle Operationen mit der Datenbank selbst zu regeln, sofern das Formular Änderungen an den Daten zuläßt. D.h., Du programmierst hier nicht von Hand alle UPDATEs/INSERTs/DELETEs, was ja gerade der große Vorteil von Access ist - schnelles Prototyping und Rapid Application Development.

Dennoch erlaubt Access Dir natürlich auch, alles selbst zu machen mit einem ungebundenen Formular. Dann mußt Du all diese Tätigkeiten im Hintergrund selbst erledigen, mußt eigene Controls entwickeln (also etwa Buttons zum Speichern usw.), den Datenaustausch dann im Detail selbst programmieren. Das ist viel Aufwand und muß natürlich auch für jedes Formular und jeden Report erneut betrieben werden.

Einzelne Werte wie einen Umsatz zu schreiben, kann man im Frontend mit VBA erledigen oder im Backend mit einer SP. Da ist dann die Frage, ob das eine oder andere besser ist, eher von anderen Dingen abhängig, etwa, ob der gleiche Vorgang aus verschiedenen Frontends durchgeführt werden soll oder anderen Tools, die dann alle eine zentrale SP verwenden könnten, da hätte die SP auch mit Zugriffsberechtigungen den Vorteil, ebenso, wenn es um komplexe Berechnungen über x Tabellen geht, die dem SQL Server alle zur Verfügung stehen. Auch hier ist die SP deutlich im Vorteil.
Wenn man eine Berechnung aus den Daten eines Datensatzes ermitteln kann, wie etwa Menge x Preis in einer Rechnung zur Ermittlung der Zeilensumme, würde man weder noch verwenden, sondern einfach ein berechnetes Feld in der Rechnungsdetailstabelle, die im Beispiel nicht persistent eingestellt werden würde und den Gesamtpreis beim Lesen der Tabelle immer automatisch mit ausgibt. Gespeichert wird dann nichts, und es braucht weder VBA noch SP. Wenn die Berechnung komplexer ist, kann man stattdessen auch eine UDF (User Defined Function) verwenden in einem berechneten Feld der Tabelle und dann auf persistent stellen. Dann wird das Ergebnis der Berechnung gespeichert, so daß eine Neuberechnung erst bei Änderung der Daten angestoßen wird. Solche verwendet man auch besonders, wenn man das Ergebnis zur schnelleren Suche indizieren möchte.

VBA und SP sind in solchen Fällen nicht nötig, es muß nichts aktiv angestoßen werden, es gibt keine Rechteprobleme und alle können die Ergebnisse jederzeit verwenden.

Es ist also immer zu überlegen, welchen Aufwand man betreiben will, wo welche Methode am vorteilhaftesten ist und die wenigsten Entwicklungskosten mit sich bringt, bei gleichzeitiger Überlegung zur Datensicherheit, die natürlich immer den Vorrang vor Aufwandskosten hat.

Gruß

Christian

[MzKlMu]

Hallo,
liege ich mit meinem Vorschlag ein gebundenes Formular zu verwenden so daneben ?

Nur mal so für mich gefragt.

[MartinHan]

Hallo,

ich bedanke mich sehr für eure Beiträge, da kann man sicherlich viel drüber schreiben.
Ich bin da vielleicht etwas Oldschool (mit 73 darf ich das auch sein...), aber bin immer noch ein Verfechter des Schichten Modells, also Daten-, Logik und Präsentationsschicht, so wie die IBM uns das in zahllosen Lehrgängen beigebracht hat.
Im Idealfall könnte man dann eine Schicht durch eine andere Technologie austauschen, aber wirklich nur im Idealfall.
Bei gebundenen Formularen bin ich doch sehr direkt auf den Daten und man ist wirklich sehr schnell damit, ungebundene haben den Vorteil, das man mehr Kontrolle hat.
Ein weiterer Aspekt ist dann noch folgender: irgendwann muss ich die Anwendung in andere Hände geben und da dachte ich, das die jungen Leute heute eher mit Java programmieren und deshalb den VBA Code reduzieren möchte, so dass die Anwendung dann z.B. Java und Azure als Basis hätte. Es ist wie gesagt keine große Anwendung, ca. 20 Tabellen ca. 30 Schlüsseltabellen, ca. 60 Formulare, ca. 15000 LoC VBA. Aber es muss schon eine sehr robuste Programmierung sein, weil wir an des Geld der Kunden gehen.

Aber wie gesagt danke für eure Beiträge ich werde heute mal eine gute Flasche Rotwein aufmachen und mir alles durch den Kopf gehen lassen.

Gruß

Martin

[MzKlMu]

Hallo,

ungebundene haben den Vorteil, das man mehr Kontrolle hat.

Vorteil, wo soll da der Vorteil liegen ?
Im MOF gab es mal einen Kommentar (zu gebunden/ungebunden) von Josef Pötzl seines Zeichens auch Mitverfasser/Beteiligter der AEK. Also ganz sicher auch Access Kenner.

Ich arbeite fast immer mit gebundenen Formulare und habe trotzdem volle Kontrolle über die Daten.

Und dieser Kommentar habe ich mir gemerkt.
Der Aufwand zur Datenvalidierung und ggf. Plausibilitätsprüfung ist ob gebunden oder ungebunden der Gleiche, aber der Aufwand zum Speichern der Daten an den richtigen Stellen (Feldern) mit dem richtigen Inhalt ist ungebunden bedeutend größer und mehr fehlerbehaftet auch.

[Bitsqueezer]

Hallo Martin,

spricht ja auch nichts gegen "old school", bin ich auch, wenn auch "nur" 57...

Schichten-Modell: Die Theorie ist ja auch eine gute, aber bezieht sich mehr auf Webanwendungen, wo man ein Frontend, eine Middle-Tier-Schicht und ein Backend hat.

In Access "verschmilzt" das zu einem Frontend und Backend. Die Middle-Schicht ist der Access-Automatismus im Hintergrund, der z.B. eine Datenzeile automatisch speichert. Das ist bei einer Webanwendung die Kommunikation mit der Datenbank, die das Frontend nicht machen muß.
So schreibst Du gerade mal "Me.Dirty = False" in VBA und löst damit eigentlich ein INSERT oder UPDATE aus, mit allem, was sich daraus ergibt, das schreibst Du nicht selbst.

Das "Dumme" hierbei ist, daß diese "Mittelschicht" halt untrennbar in Access existiert und bei Wechsel der Frontendtechnologie kann diese nicht ausgetauscht werden, wenn man also Access wegläßt, gibt es keinen Ersatz für die Mittelschicht. Hat man etwa eine Webanwendung mit einem Applikationsserver als Mittelschicht, kann man hier die APIs in Richtung Frontend und Backend beibehalten und die Funktionalität in der Mitte austauschen. Allerdings ist das auch eher "ideales Wunschdenken". Die einzelnen, auch mittlerweile verfügbaren Lösungen verwenden selbst auch keine Mittelschicht, die man beliebig austauschen könnte. Wenn man z.B. PowerApps verwendet, hat dieses sein eigenes Datenbankhandling, daß der PA-Programmierer ebenfalls nicht ändern kann (noch weit weniger als der VBA-Programmierer selbständig eingreifen kann). Ebenso PowerBI oder was auch immer.

Es gibt darüber hinaus aber natürlich die Möglichkeit, die Schnittstellen direkt in der Datenbank anzubieten, das setzt aber profundes Wissen über die Möglichkeiten voraus.

Man kann beispielsweise die Tabellen per Sicherheitseinstellungen komplett "unsichtbar" machen für alle Anwendungen und alle Arbeit mit allen Frontends über Views/UDFs/SPs regeln. Das ist durchaus keine schlechte Idee, weil man so die Zugriffsrechte sehr exakt regeln kann und vor allem das DB-Design komplett (oder wenigstens weinigermaßen) von der Anwendung entkoppeln kann. Wenn Du etwa ein Feld in zwei aufteilst oder einen Feldnamen umbenennen willst, dann kannst Du das tun, mußt danach nur die zugehörigen Views etc. anpassen, so daß sie "nach außen" hin immer noch das gleiche machen. Eine View kann auch per Schemabinding an Tabellen gebunden werden, dann kann man sie mit einem INSTEAD OF-Trigger so anpassen, daß man mit einer View über mehrere Tabellen Daten ändern kann, als wäre es eine einzige Tabelle - was sonst nicht so einfach geht. Die View ist dann auch selbst indizierbar. Nachteil hier ist, daß die betroffenen Tabellen dann auch im Design nicht mehr angepaßt werden können.

So eine Schnittstelle kann man aber mit "einfachen" Views etwa sehr gut an Access anbinden und hat dann beide Vorteile: Man kann die View wie eine Tabelle mit Access verlinken und hat alle Automatismen der "Mittelschicht" von Access, die Daten automatisch durch gebundene Formulare bearbeiten zu können - und hat dennoch eine eigene Möglichkeit, die Views separat mit Rechten zu versehen, so daß man sie auch gezielt für Anwendungsfälle unterschiedlich gestalten kann. So kann man etwa einer Gruppe Zugriffsrechte auf Personen-Namen und Mailadressen geben und eine andere kann alle Daten ansehen - über zwei Views mit unterschiedlichen Rechten und Feldern, obwohl beide die gleiche Tabelle verwenden. Ist nur ein Trivialbeispiel natürlich, nicht unbedingt praxistauglich.

SQL Server bietet auch "Application Roles", was wieder ein Thema für sich ist.

Du hast also sehr viele Möglichkeiten, eine Anwendung zu gestalten. Aber insbesondere, wenn das Budget knapp ist, würde ich mir gut überlegen, auf die Automatismen zu verzichten, da sie das Highlight von Access sind und sehr viele eigene Programmierfehler beim "manuellen Design" verhindern. Wenn Du darauf verzichtest, kann man auch gleich zu einer anderen Frontendtechnologie wechseln, da man dann hier in Access keine wirklichen Vorteile mehr hat.
Beispielsweise ein .NET-Frontend, bei dem Du viele der Automatismen von Access nur noch "halbautomatisch" vorfindest und dafür die volle Freiheit in der Programmierung und grafischen Gestaltung hast (etwa ein 3D-Formular, das perspektivisch in den Raum geht und trotzdem voll funktionsfähig ist...mach das mal mit Access.. ).

In Access kannst Du, einfach gesagt, eine Tabelle/eine View verlinken, Access liest die Metadaten aus, fragt, wenn es nicht selbst den PK findet, den Du dann selbst auswählen mußt, und Du kannst bereits mit Doppelklick auf den Link mit den Daten arbeiten. Und nach dem Öffnen der verlinkten Tabelle klickst Du auf Formular erstellen, suchst Dir den Typ aus, und Access baut eine komplette Benutzeroberfläche zu der Tabelle für Dich, die prinzipiell erst mal keine Zeile Code mehr erfordert, um voll funktionsfähig zu sein. Du kannst also eine komplette Funktionalität erstellen mit EINER Funktion. Such Dir mal ein anderes Frontend, was das kann.

Der Code hält sich so nun auch sehr gering, weil Du Dich i.d.R. um die Speicherung der Daten nicht kümmern mußt. Bei Designänderung der Tabelle mußt Du neu verlinken, aber alles, was die gleichen Namen hat, "kennt" seine Felder nachher auch weiterhin. Alles manuell zu erledigen, wenn Du das coden willst. Der Aufwand ist ziemlich groß, der Nutzen ziemlich gering.

Wenn man sich entschieden hat, Access als Frontend zu verwenden, kann man dennoch den Codeaufwand in VBA so gut wie möglich begrenzen. Beispielsweise ist es eher sinnfrei, in VBA durch z.B. zwei verschachtelte Recordsets aus zwei SQL-Tabellen zu schleifen, um irgendwelche Daten miteinander zu verwursteln. Genau hier ist dann die Stärke der SPs in SQL Server: Du kannst die Daten über extrem performante SQL-Befehle dort verarbeiten, wo sie bereits sind, mit getrennter Rechenpower, mit allen Vorzügen, die der Server bereitstellt.
Und wenn Du dann mal das Frontend (die Technologie) wechseln mußt, ist die komplizierte Berechnung in einer SP auf dem Server und kann einfach vom nächsten Frontend weitergenutzt werden - z.B. auch parallel zu Access von einem Reporting Server (SSRS ist in SQL Server ja schon "mit dabei"). Wenn die Berechnung nur in VBA existiert, kann der SSRS damit nicht arbeiten. Also überflüssige Arbeit UND schlechte Performance. Genau hier spielen SPs ihre Stärken aus. Nebenbei kann man hier mit "EXECUTE AS" auch noch eine Berechtigungsstuf erhöhen, wenn die SP etwa Daten benötigt, auf die der Benutzer der Access-Anwendung, der sie aufgerufen hat, keine Zugriffsrechte hat. So kann die SP damit arbeiten, auch wenn der Benutzer es nicht kann.

Für den Zweck dagegen, einfache Speicherung von Datenzeilen eines Formulares je eine SP zu bauen, das ist i.d.R. mit Kanonen auf Spatzen schießen und bietet auch keine Performance-Vorteile, da es ja nur um eine Datenzeile geht (i.d.R.). Wenn man dagegen z.B. eine CSV-Tabelle hochladen will, ist eine SP schon wieder eine bessere Lösung.

Daher sage ich ja, man kann keine generelle Antwort auf die Frage geben, es gibt nicht DIE Lösung, sondern nur die Abwägung, was im spezifischen Fall besser ist. Wenn das Budget gering ist und entsprechend die Entwicklungszeit minimiert werden muß, gibt es kaum eine bessere Frontend-Technik als Access (aber unter der Prämisse, seine Automatismen so gut wie möglich zu verwenden). Das spricht nicht dem Sicherheitskonzept entgegen, da man die Tabellen über Views etc. kapseln kann (natürlich kann man auch immer mit den Tabellen direkt arbeiten, ich persönlich versuche das immer zu vermeiden).

Wenn man ein riesiges Budget hat und am besten noch Entwicklungstools, die einem Datenklassen auswerfen für DB-Objekte, oder wo man eine Applikations-Server-Schicht aufbauen kann, um verschiedenste Frontends gegen die Datenbank abzuschotten usw. - ja, warum nicht? Kostet nur erheblich mehr, es gibt weit mehr Fehlerquellen und Performance wird auch nicht unbedingt schneller dadurch.
Wie oft wurde so eine Mittelschicht tatsächlich in den letzten Jahrzehnten mal ausgetauscht? Also in meinen >30 Jahren Berufserfahrung hatte ich das noch bei keinem Projekt erlebt. I.d.R. will man Frontends aufbessern, und da geht es meist um Geschwindigkeit, unabhängiges Arbeiten Offline oder auch Arbeiten per Internetzugriff.
Es lohnt also nicht, sich auf eine etwaige Zukunft einzustellen, die dann nie eintritt. Besonders nicht, wenn der Aufwand dann so groß ist, daß es die Nutzung der Anwendung JETZT völlig verzögert.

Gruß

Christian

[PhilS]

liege ich mit meinem Vorschlag ein gebundenes Formular zu verwenden so daneben ?

Ich bin bei der Fragestellung "VB oder SP" davon ausgegangen, dass es hier nicht um eine direkte manuelle Dateneingabe geht, sondern um einen automatischen Prozess der irgendwo an einer Benutzeraktion versteckt hintendran abläuft. Also dass ein Formular, gebunden oder ungebunden, gar nicht Teil der Frage ist.

[markusxy]

Ich arbeite fast immer mit gebundenen Formulare und habe trotzdem volle Kontrolle über die Daten.

Und warum nur fast immer?

Access verfolgt einen Ansatz, der es sehr einfach macht ohne tiefergehende Programmierkenntnisse schnell zu einem Ergebnis zu kommen, dafür muss man bei höheren Ansprüchen Abstriche machen.
Natürlich kann man auch ungebunden arbeiten und selbst ein paar Klassen entwerfen die die ganze Funktionalität der gebundenen Formulare nachbilden dafür aber dann weit mehr können als Access anbietet.

Habe ich selbst in Verwendung, aber mittlerweile würde ich so was nicht mehr in Access entwickeln.

Denn warum sollte man bei gehobenen Ansprüchen Access verwenden das nur 2% der Möglichkeiten einer vernünftigen Entwicklungsumgebung anbietet?

[MzKlMu]

Hallo,

Und warum nur fast immer?

Das weis ich nicht, denn das Zitat ist nicht von mir.
Aber "fast" ist schon OK. Es gibt manchmal Vorhaben wo ungebundene Felder Vorteile bieten.
Z.B. wenn man neue Daten immer oben einfügen will. Was gerade vor kurzem hier im Forum ein Thema war.

[markusxy]

@klaus, das war ein Scherz 

[MzKlMu]

@Markus 
Ich darf auch mal auf der Leitung stehen.  

[MartinHan]

Hi,

nachdem das Christkind weg war...habe ich etwas gebastelt und einige STP geschrieben.
Vom Prinzip her gefällt mir das schon ganz gut auch die Performance passt, wobei ich so geringe Datenmenge habe, das ein Unterschied zu VBA wohl nicht meßbar sein wird.
Ein kleines Problem gibt es aber...ich habe die DB aus der Produktion geladen...und danach waren dann die STP. die ich in der Entwicklung hatte, futsch...
Da muss man also aufpassen.
Z.B. könnte man die Prod-Daten in eine temporäre DB laden, aus der man dann die Daten in der Entwicklung auffrischt.
Man lernt nie aus...

Martin

[Bitsqueezer]

Hallo Martin,

ja, zu diesem Zweck empfehle ich Dir, wenn Du nicht in teure Tools investieren möchtest, einfach die Visual Studio Community Edition herunterzuladen und zu installieren, dazu dann die SQL Server Tools.

Hier kannst Du dann ein Tool starten, mit dem Du Schema und/oder Daten von zwei Datenbanken miteinander vergleichen kannst. Wenn Du die Daten aus der Produktion in einem Backup auf dem Entwicklungsrechner einspielst (dort natürlich unter einem anderen Namen), dann kann Dir das Tool z.B. einfach die SPs miteinander vergleichen und Du siehst, was Du von wo nach wo laden mußt (oder nicht laden, um nichts zu überschreiben). Außerdem generiert Dir das Tool auch auf Wunsch gleich ein komplettes Skript, womit die eine Datenbank an die andere angepaßt wird.

Für professionelle Verwendung empfiehlt sich eher sowas wie RedGate, das nochmal um Längen besser ist, aber es kostet halt auch nicht wenig. Wenn kein Budget dazu da ist, tut es Visual Studio auch.

Nebenbei kannst Du natürlich auch gleich Deine Entwicklung mit Visual Studio durchführen (was nicht mein persönlicher Weg ist, aber nur, um es zu erwähnen). Man kann mit Visual Studio das Datenbankprojekt komplett übernehmen, d.h., es werden alle Entwicklungen inkl. Tabellendesign, SPs, Views usw. als Objekte in Visual Studio in einem Projekt gespeichert, und Visual Studio kann dieses Gesamtprojekt dann mit einer bestehenden Datenbank vergleichen und die Zieldatenbank anpassen. So kannst Du z.B. die Sourcecodes in VS entwickeln und dann auf die Zieldatenbank übertragen. Ebenso ist auch eine Sourcecodeverwaltung wie Github möglich, wenn man das möchte.
Ich persönlich entwickele lieber immer direkt auf SSMS, was ja auch ein Derivat von VS ist, auch wenn die Projekete, die man hier anlegen kann, nicht viel mehr als eine "Skriptsammlung" sind, mir genügt's. Aber das muß jeder selbst wissen. Für Vergleiche zwischen zwei Datenbanken nehme ich auch i.d.R. VS.

Wümsche frohe Weihnachten,

Christian