Re: zentrale DB2-Zugriffs-Module

Geschrieben von Gernot Ruban on März 03, 2001 um 19:04:

Als Antwort auf zentrale DB2-Zugriffs-Module geschrieben von Peter Lorez on Februar 26, 2001 um 13:38:

Hallo!

Ich weiß, ist düfte schwer sein dagegenzulenken, aber ...

Man kann immer nur von solchen zentralen Zugriffsmoduln abraten!
1) Die Anwendungsentwickler verlieren die Übersicht über die Details. Das bedeutet letzten Endes, das für die Abwicklung von Tests immer ganze und komplette Testdatenumgebungen hergestellt werden müssen - mit entspr. Aufwand.
2) Zuviele Operationen werden ausgeführt und zuviele Daten verarbeitet, weil die Vielfalt der Anfragen vor Beginn der Entwicklung garnicht feststehen kann. Beispiel: Alle Spalten werden selektiert: Höhere I/O Zeiten, Sort Aufwand, Speicherplatz, Decompression etc
3) DB2 bzw der Optimizer trifft nun ein Package mit SEL/INS/UP/DEL - was soll es davon halten. Welche Initial Sperren werden verhängt?
4) Bei Performance Analysen tut man sich sehr sehr schwer, denn an Logik ist in den zentralen Zugriffsmoduln ja nun nicht mehr viel enthalten. Jeder Funktion KÖNNTE ausgeführt werden.
5) Dadurch, dass man nicht weiß und wissen kann, welche Packages wo eingesetzt werden, wird vermutlich ein riesiger Plan entstehen, der alle Packages enthält.
6) Es droht, dass Join Operationen codiert werden und nicht DB2 überlassen werden.

Mir würde noch mehr einfallen - sei's drum. Meine Empfehlungen lauten denn wenigsten ...
a) Einen Code Generator entwickeln
b) Die Moduln wenigsten separieren nach SEL und INS/DEL/UPD
c) eine Trace Funktion vorsehen
d) Standard-Fehlerbehandlung entwickeln

Good Luck
Gruß
Gernit

Antworten:

Re: zentrale DB2-Zugriffs-Module U. Mayer 09:52 13.3.2001 (0)

Schreibe eine Antwort

Name:
E-Mail:

Thema:

Kommentar:
: Hallo! : Ich weiß, ist düfte schwer sein dagegenzulenken, aber ... : Man kann immer nur von solchen zentralen Zugriffsmoduln abraten! : 1) Die Anwendungsentwickler verlieren die Übersicht über die Details. Das bedeutet letzten Endes, das für die Abwicklung von Tests immer ganze und komplette Testdatenumgebungen hergestellt werden müssen - mit entspr. Aufwand. : 2) Zuviele Operationen werden ausgeführt und zuviele Daten verarbeitet, weil die Vielfalt der Anfragen vor Beginn der Entwicklung garnicht feststehen kann. Beispiel: Alle Spalten werden selektiert: Höhere I/O Zeiten, Sort Aufwand, Speicherplatz, Decompression etc : 3) DB2 bzw der Optimizer trifft nun ein Package mit SEL/INS/UP/DEL - was soll es davon halten. Welche Initial Sperren werden verhängt? : 4) Bei Performance Analysen tut man sich sehr sehr schwer, denn an Logik ist in den zentralen Zugriffsmoduln ja nun nicht mehr viel enthalten. Jeder Funktion KÖNNTE ausgeführt werden. : 5) Dadurch, dass man nicht weiß und wissen kann, welche Packages wo eingesetzt werden, wird vermutlich ein riesiger Plan entstehen, der alle Packages enthält. : 6) Es droht, dass Join Operationen codiert werden und nicht DB2 überlassen werden. : Mir würde noch mehr einfallen - sei's drum. Meine Empfehlungen lauten denn wenigsten ... : a) Einen Code Generator entwickeln : b) Die Moduln wenigsten separieren nach SEL und INS/DEL/UPD : c) eine Trace Funktion vorsehen : d) Standard-Fehlerbehandlung entwickeln : Good Luck : Gruß : Gernit

Optionale Link URL:
Link Titel:
Optionale Image URL:

[ Antworten ] [ Forum ]