Satzsperre

[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