View Full Version : Satzsperre
@Bender
Sorry aber sehe ich gänzlich anders.
Es ist beabsichtigt, daß die PF ohne Key ist. Und bei entsprechender Disziplin, die über ein keylose Datei eingefordert wird, werden in keinster Weise "Ferkeleien" herbeigeführt.
Solch eine Logik führt letztlich zu einer homogenen Entwicklungsumgebung und das ist im Sinne eines jeden Unternehmens. Natürlich wird die Arbeit mit einigen Tools erschwert.
BTW : Diese Logik läuft bei bei 2 meiner ehemaligen Kunden seit ca. 15 Jahren. Es ist keine Satzsperre bekannt. Beide Pakete sind innerhalb dieser 15 Jahre stetig gewachsen und sind auch heute noch gut pfleg- und lesbar.
Hallo,
das habe ich nie bezweifelt, dass wir das verschieden sehen. Ich weiss allerdings Herrn Codd auf meiner Seite, der vor gut 30 Jahren die theoretischen Grundlagen für relationale Datenbanksysteme gelegt hat und da ist die Existenz von primary Keys erste Grundvoraussetzung. Die Verarbeitung nach relativer Satznummer ist im Grunde genommen sequentielle Datenhaltung, das geht auch - früher hatte man nichts besseres, aber einer Datenbankmaschine, wie der AS400 ist das nicht angemessen.
mfg
Dieter Bender
@Bender
Sorry aber sehe ich gänzlich anders.
Es ist beabsichtigt, daß die PF ohne Key ist. Und bei entsprechender Disziplin, die über ein keylose Datei eingefordert wird, werden in keinster Weise "Ferkeleien" herbeigeführt.
Solch eine Logik führt letztlich zu einer homogenen Entwicklungsumgebung und das ist im Sinne eines jeden Unternehmens. Natürlich wird die Arbeit mit einigen Tools erschwert.
BTW : Diese Logik läuft bei bei 2 meiner ehemaligen Kunden seit ca. 15 Jahren. Es ist keine Satzsperre bekannt. Beide Pakete sind innerhalb dieser 15 Jahre stetig gewachsen und sind auch heute noch gut pfleg- und lesbar.
Commit Verwendung macht eigentlich nur mit embedded SQL und Schichtentrennung Spass und dann wird immer Committed bevor die Steuerung aus der Datenbank-Zugriffs Schicht nach oben geht und das war's.
Das Problem, dass viele von uns wahrscheinlich haben, ist, dass wir mit gewachsenen Anwendungen und Datenbanken, natürlich DDS-beschrieben, kämpfen müssen. SQL hat erst in den letzten paar Releasen wirklich an Bedeutung gewonnen. Das Haupt-Problem, was viele nicht sehen wollen, ist i.d.R., dass sich in der Datenbank über die Jahre jede Menge "Müll" (Redundanzen, überflüssige Zugriffswege) angesammelt hat. Bevor man allerdings daran etwas dreht, überlegt man zuerst, ob die RPG-Programm in JAVA umgestrickt werden sollten, und wundert sich dann, dass die Performance noch bescheidener ist.
Dem Einsatz von Embedded SQL steht man noch eher skeptisch gegenüber. (Ich musste schon Programme von Embedded SQL auf RPG umstellen, obwohl die SQL-Variante nachweislich schneller war). Ausserdem ist embedded SQL ist nur auf den ersten Blick einfach! Man muss schon wissen was man tut, bzw. man muss jedes SQL-Statement analysieren, und kann dann, wenn man das ganze auf eine andere Maschine mit anderem Release und andere Datenkonstellation transferiert, ein böses Erwachen erleben.
Da ist es doch einfacher eine vorhandene logische Datei in den F-Bestimmungen zu definieren, da weiss man was man hat! (Das ist nicht unbedingt meine Meinung, aber eine allgemein sehr verbreitete)
Es ist allerdings nicht so einfach, zu behaupten, erst dann wenn man aus der Datenbank-Schicht kommt, den Commit zu setzen. Es ist z.B. unverantworlich, einen kompletten Auslagerungs-Lauf, mit hunderten von Aufträgen unter einem einzigen Commit laufen zu lassen. Da muss schon mehr differenziert werden.
Birgitta
Tja ja, Anwendungsdesign wurde schon immer sträflich vernachlässigt (zugegeben mache ich das auch).
Meine erste Applikation auf AS/400 war V2R1 mit COBOL, Journalisierung und Commit/Rollback ! Was wir da an Design im Voraus entwickelten, hat uns bei der Realisierung erheblich geholfen.
Klar stieß man damals an die Commit-Grenze von 32766 Sätzen (jetzt ca. 0,5 Mio). Aber wer benötigt denn schon so große Transaktionen ?!
Allein was wir an Recovery-Programmen gespart haben, da per Rollback ja jederzeit ein konsistenter Stand gewährleistet wurde.
Sinnvolle Transaktionsdefinition und schon klappts mit der Performance.
Naja, und mit Java und SQL soll ja eh alles automatisch gehen, woll ?
Hallo Birgitta,
ich habe auch mal RPG II programmiert (und COBOL auf Mainframe und das ist noch übler).
Zu dem SQL und dem einfach:
90 Prozent der Programme (und alle typischen Dialogprogramme sind mit SQL einfacher abzubilden. Begründung: 2/3 der Logik beschäftigen sich mit Daten zusammen grabschen und das kann durch ein SQL Statement ersetzt werden.
30 Prozent der Programme fallen bei der Umstellung auf SQL weg, da sie sich nur in der Sortierfolge, oder ähnlichem von einem anderen Programm unterscheiden.
Es bleibt ein kleiner Rest, der sauberes umgehen mit SQL erfordert - in diese Ecke gehört auch Transaktions Sicherheit (was die meisten RPG Rekord Löffel Exzess Programme nicht sind).
Ein Satz noch zu Schichtentrennung:
Die Steuerung eines Batch Jobs ist Business Logik, die Datenbankzugriffsschicht sagt nach der Verarbeitung jedes Satzes Commit, wo ist da das Problem? Gerade durch saubere Schichtentrennung wird das einfacher (bis auf den Krampf mit den Activation Groups, weil man nur einmal Connecten darf- aber das ist ein völlig anderes Thema).
Dieter
Hallo Birgitta,
ich habe auch mal RPG II programmiert (und COBOL auf Mainframe und das ist noch übler).
Zu dem SQL und dem einfach:
90 Prozent der Programme (und alle typischen Dialogprogramme sind mit SQL einfacher abzubilden. Begründung: 2/3 der Logik beschäftigen sich mit Daten zusammen grabschen und das kann durch ein SQL Statement ersetzt werden.
30 Prozent der Programme fallen bei der Umstellung auf SQL weg, da sie sich nur in der Sortierfolge, oder ähnlichem von einem anderen Programm unterscheiden.
Es bleibt ein kleiner Rest, der sauberes umgehen mit SQL erfordert - in diese Ecke gehört auch Transaktions Sicherheit (was die meisten RPG Rekord Löffel Exzess Programme nicht sind).
Ein Satz noch zu Schichtentrennung:
Die Steuerung eines Batch Jobs ist Business Logik, die Datenbankzugriffsschicht sagt nach der Verarbeitung jedes Satzes Commit, wo ist da das Problem? Gerade durch saubere Schichtentrennung wird das einfacher (bis auf den Krampf mit den Activation Groups, weil man nur einmal Connecten darf- aber das ist ein völlig anderes Thema).
Dieter
Hallo Dieter,
ich habe ja auch nichts gegen embedded SQL gesagt! Und mit einfach habe ich eigentlich nur gemeint, dass man einigermaßen wissen sollte, wie SQL funktionniert, auch wenn die Entscheidungen des Optimizers nicht immer nachvollziehbar sind.
Wenn es nach mir ginge, gäbe es keine F-Bestimmungen mehr in den RPG-Programmen. Durch geschickte Views könnten selbst etwas weniger versionierte RPG-Programmierer embedded SQL einsetzen. Vermutlich würden hunderte von Zugriffs-Wegen (bzw. logische Dateien) überflüssig werden, die heute alle mit Zugriffs-Pfadwartung *IMMED erstellt sind, da ein Unique Key auf der Datei liegt. Nur leider kann man nicht von heute auf morgen hunderte Programme (die problemlos laufen) auf embedded SQL umstellen. Performance hin oder her.
Ich würde noch viel weiter gehen und viel mehr Funktionalität, z.B. über Referentielle Integritäten und Trigger in die Datenbank packen. Am liebsten würde ich die komplette Datei-Verarbeitung direkt in SQL programmieren und als Stored Procedures aufrufen. Das RPG (oder was auch immer)-Programm würde nur noch steuern, also nur noch aus Programm- und Prozedur-Aufrufen bestehen.
Aber man gerät leider immer noch sehr oft an recht konservative Ansichten, die teilweise sogar soweit gehen, warum RPGIV in RPGIII geht doch alles.
Birgitta
Hallo,
das habe ich nie bezweifelt, dass wir das verschieden sehen. Ich weiss allerdings Herrn Codd auf meiner Seite, der vor gut 30 Jahren die theoretischen Grundlagen für relationale Datenbanksysteme gelegt hat und da ist die Existenz von primary Keys erste Grundvoraussetzung. Die Verarbeitung nach relativer Satznummer ist im Grunde genommen sequentielle Datenhaltung, das geht auch - früher hatte man nichts besseres, aber einer Datenbankmaschine, wie der AS400 ist das nicht angemessen.
mfg
Dieter Bender
Herrn Codd wird nicht wiedersprochen und es wird auch nicht gegen ihn gearbeitet, es wird lediglich der Zugriff auf eine physische Datei erschwert. Damit existiert im Maximum eine zusätzliche logische Datei(wahrscheinlich gäbe es sie sowieso). Wir sind uns sicherlich darüber einig, das der qualifizierte Zugriff über die relative Satznummer nichts mit sequentieller Datenhaltung zu tun hat. Ein fehlender Key sagt über die Art der Datenhaltung nicht wirklich etwas aus weder über die Art noch über den Grad der Normalisierung.
Zäumen wir das Pferd von hinten auf. Das Ziel wird erreicht.
@Birgitta,
ich habe einen wesentlichen Vorteil: ich kann mich als OneManShow auf Aufträge konzentirieren, wo man technologisch nach vorne will und nicht die Vergangenheit zurück holen will.
Das Thema mit den Funktionalitäten in die Datenbank verlagern wäre vielleicht irgendwann mal eine interessante Diskussion wert, das läuft gegenwärtig wieder in die umgekehrte Richtung (Stichwort Enterprise Java Beans) und auch das kann auch seinen Charme haben.
@Wuntvor
Codd's 2. Regel:
2. The guaranteed access rule
This rule is essentially a restatement of the fundamental requirement for primary keys.
It says that every individual scalar value in the database must be logically addressable
by specifying the mane of the containing table, the name of the containing column and the
primary key value of the containing row.
(nach: http://www.databaseanswers.com/codds_rules.htm)
Ob man das jetzt als Access Path für das PF oder als Key einer logical anlegt ist eine andere Frage. Ich würde das eh' mit SQL machen und als Constraint anlegen.
Zugriffe auf das PF Objekt würde ich generell nicht machen, sondern grundsätzlich mit SQL auf SQL erstellte Views zugreifen, das entkoppelt die Anwendung von der Datenbank.
Der Zugriff über relative Satznummer hat durchaus mit sequentileer Verarbeitung zu tun, das sieht sogar der Query Optimizer des Datenbanksystems so und produziert full Table scans, wenn man die SQL Funktion RRN verwendet.
Normalisierung setzt die Existenz von Keys voraus, wenn eine Kundendatei keinen Key hat, dann kann ich schließlich keinen Kunden über seinen Key in dr Auftragsdatei kennzeichnen, nach meinem Verständnis zumindest.
mfg
Dieter Bender
@Birgitta,
ich habe einen wesentlichen Vorteil: ich kann mich als OneManShow auf Aufträge konzentirieren, wo man technologisch nach vorne will und nicht die Vergangenheit zurück holen will.
Das Thema mit den Funktionalitäten in die Datenbank verlagern wäre vielleicht irgendwann mal eine interessante Diskussion wert, das läuft gegenwärtig wieder in die umgekehrte Richtung (Stichwort Enterprise Java Beans) und auch das kann auch seinen Charme haben.
@Wuntvor
Codd's 2. Regel:
2. The guaranteed access rule
This rule is essentially a restatement of the fundamental requirement for primary keys.
It says that every individual scalar value in the database must be logically addressable
by specifying the mane of the containing table, the name of the containing column and the
primary key value of the containing row.
(nach: http://www.databaseanswers.com/codds_rules.htm)
Ob man das jetzt als Access Path für das PF oder als Key einer logical anlegt ist eine andere Frage. Ich würde das eh' mit SQL machen und als Constraint anlegen.
Zugriffe auf das PF Objekt würde ich generell nicht machen, sondern grundsätzlich mit SQL auf SQL erstellte Views zugreifen, das entkoppelt die Anwendung von der Datenbank.
Der Zugriff über relative Satznummer hat durchaus mit sequentileer Verarbeitung zu tun, das sieht sogar der Query Optimizer des Datenbanksystems so und produziert full Table scans, wenn man die SQL Funktion RRN verwendet.
Normalisierung setzt die Existenz von Keys voraus, wenn eine Kundendatei keinen Key hat, dann kann ich schließlich keinen Kunden über seinen Key in dr Auftragsdatei kennzeichnen, nach meinem Verständnis zumindest.
mfg
Dieter Bender
Sowohl die relative Satznummer einer PF als auch der Key des LF ist ein eindeutiger Key und entspricht der Definition Codds eines primary Keys(My 2 cents). Eine "Schwäche" des Query Optimizers ist kein Argument dagegen. In RPG kann ich durchaus direkt einen Zugriff auf einen qualifizierten Datensatz nehmen. Der einzige Unterschied zu dem Begriff liegt darin, daß ich die RRN nicht selber verwalte, was aber auch garnicht in meinem Interesse liegt.
Ich Stimme dir zu, daß zu einer Normalisierung auch Schlüsselbegriffe gehören, aber selbige existieren ja auch in unserem Diskussionsbeispiel.
Deiner Aussage, daß man/du keine Zugriffe auf eine PF machen sollte stimme ich voll und ganz zu.
Ich glaube wir haben nur eine unterschiedliche Betrachtungsweise. Bei einem Paket, welches in RPG repsektive ILE codiert wurde nutze ich die Datenbank der AS/400 und eben nur RPG; sagen wir ADTS. Tools die extern den, ändernden, Zugriff auf diese Datenbank erlauben möchte ich als weit als möglich vermeiden, da dies der Definition einer homogenen Entwicklungs-/Laufumgebung wiederspricht.
Solch eine heterogene Umgebung kann ich meiner Meinung nach, nur auf einer "grünen Wiese" konzepieren und umsetzen. Wohin der nachträgliche Einsatz führt, sehe ich gerade auf meiner aktuellen Arbeiststelle.
Unter diesen Betrachtungspunkten erreicht man, mit der vor ca. 8000 Worten beschriebenen Lösung, direkt das Ziel.
Hallo Wuntvor,
Die RRN ist Bestandteil der Art physischen Speicherung, sie ist zwar eindeutig, aber eben kein Key. Wenn ich sie als "Pseudo" Key verwende, um Referenzen auf Satzebene abzubilden (Foreign Key), dann darf ich weder Reuse Deleted records verwenden, noch RGZPFM machen, da sich dann ja der Pseudo Key ändern würde und genau das ist sequentielle Datenhaltung.
Der einzige Unterschied zu dem Begriff liegt darin, daß ich die RRN nicht selber verwalte, was aber auch garnicht in meinem Interesse liegt.
Ich glaube wir haben nur eine unterschiedliche Betrachtungsweise.
Das ist in der Tat der Kernpunkt. Du hast eine Applikation im Hinterkopf, wie sie vor Jahren programmiert wurde. Ich betrachte das Ganze tatsächlich von der "grünen Wiese" aus: wie würde man das machen, wenn man heute damit anfangen würde eine Applikation von Null an zu schreiben. Damit ist nichts darüber ausgesagt, ob es zweckmäßig ist jede vorhandene Anwendung dahin zu bringen und wenn ja wie, dazu würde ich mir in einem Forum ohne Kenntnis der konkreten Anwendung nie ein Urteil erlauben.
mfg
Dieter Bender