Satzsperre

[Wuntvor]

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

[BenderD]

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.

[Wuntvor]

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.

[BenderD]

@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

[Wuntvor]

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

[BenderD]

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

[Rincewind]

*einmisch*

und natürlich *vom thema mal wegführ*

Physische Dateien ohne Schlüssel machen Sinn.
Bei Häufigen Plattenfehlern kann man die nämlich leichter wieder zusammenkopieren (so sie denn sequentiell fortgeschrieben werden).

Der Erste logische Zugriffsschlüssel ist dann der UNIQUE Zugriffskey
So wird auch alles Eindeutig zuordbar.


Rince

P.S. Zum Thema Satzsperre: Wir haben den ganz normalen 60 Sekunden Warten und dann auf die Nachricht reagieren (so wie man es damals halt machte..)
Neuerdings bin ich aber Fan der Satzsperrenabfrage im Programm (und dann einen Bildschirm ausgeben wer hier wen sperrt)
Dann klären die User das Per Telefon selbst (Stundenlanges Blockieren weil man vor der Besprechung nicht aus dem PGM geht und so... Alles schön dem User überlassen, da werden die Leute von selbst vorsichtiger)

[BenderD]

Hallo Rince,

ersteres ist ein völlig anderes Thema, nämlich ein Datenbank internes Thema, wie eine primary Key constraint abgebildet wird.

*einmisch*

und natürlich *vom thema mal wegführ*

Physische Dateien ohne Schlüssel machen Sinn.
Bei Häufigen Plattenfehlern kann man die nämlich leichter wieder zusammenkopieren (so sie denn sequentiell fortgeschrieben werden).

Der Erste logische Zugriffsschlüssel ist dann der UNIQUE Zugriffskey
So wird auch alles Eindeutig zuordbar.


Rince

P.S. Zum Thema Satzsperre: Wir haben den ganz normalen 60 Sekunden Warten und dann auf die Nachricht reagieren (so wie man es damals halt machte..)
Neuerdings bin ich aber Fan der Satzsperrenabfrage im Programm (und dann einen Bildschirm ausgeben wer hier wen sperrt)
Dann klären die User das Per Telefon selbst (Stundenlanges Blockieren weil man vor der Besprechung nicht aus dem PGM geht und so... Alles schön dem User überlassen, da werden die Leute von selbst vorsichtiger)

Zum PS: greift m.E. zu kurz. Wenn solche Sperren auftreten, dann sind davon auch nicht interaktive Jobs betroffen und es hilft einem (Beispiel) Batch oder Server Job wenig, wenn ich ihm sage welcher interaktive Job einen Satz die nächsten 3 Stunden sperrt.

Dieter Bender