Key-Tabelle oder SQL-Sequence?

[Allrounder]

Folgende Situation:
Das eindeutige Key-Feld einer PF hat den Nachteil, dass es aus einer laufenden Nummer und einer Auftragsnummer zusammengesetzt ist. Um Inhalt in Keyfeldern zukünftig zu vermeiden, wollen wir im ersten Schritt zum Jahreswechsel dieses Keyfeld mit einer eindeutigen ID füllen, ohne Inhalt nur fortlaufend.
(Zweiter Schritt ist der Umstieg auf eine SQL-Tabelle mit Auto-Increment, aber jetzt noch kein Thema).
Die ID soll auch mit einer Prüfziffer versehen werden.

Die Frage ist, welche Variante am sinnvollsten ist.

Ich tendiere zu einer Prozedur, die eine Keytabelle oder eine SQL-Sequence (oder einen Datenbereich?) ausliest und die ID mit generierter Prüfziffer zurückgibt.

Sind Sequenzen zu empfehlen? Habe noch keine Erfahrung damit.
Und wie vermeide ich am besten Kollisionen beim Zugriff auf eine Keytabelle? Oder ist der gute alte Datenbereich die beste Lösung?

Danke im Voraus für Eure Meinungen.

[kuempi von stein]

*nachdenk*

also zuerst wollte ich antworten, dass wir das hier mit nem Datenbereich gelöst haben (Altanwendung)

dann wollte ich vorschlagen, ein Keyfeld aus Datum/Zeit/Jobnummer zu bilden, sollte einzigartig sein....

Aaaber....
ich frage mich, wozu Ihr überhaupt ein Keyfeld braucht, wenns doch keinen Inhalt hat?
Also die ketzerische Frage lautet:
Warum nicht gleich ganz abschaffen?

kuempi

[BenderD]

Hallo,

Tabelle ist um Längen besser als DTAARA, weil man eine Tabelle für alle Keys verwenden und das Sperrverhalten unter SQL feinkörnig steuern kann. Wenn man keine lückenlose Sequenz braucht, kann man für Performance Optimierung blocken (Standardroutine zieht sich n Keys, die dann in der aktuellen Aktivierung benutzt werden. SQL Auto Increment Felder machen im Grunde dasselbe, Eigenprogrammierung ist etwas flexibler.

mfg

Dieter Bender

PS für die Ketzter, die ansonsten meine Sympathie genießen: Keyfelder ohne semantischen Inhalt haben den Vorteil, dass bei Änderung Referenzen erhalten bleiben (im Beispiel: Zusammenfasssung zweier Aufträge zu einem)

Folgende Situation:
Das eindeutige Key-Feld einer PF hat den Nachteil, dass es aus einer laufenden Nummer und einer Auftragsnummer zusammengesetzt ist. Um Inhalt in Keyfeldern zukünftig zu vermeiden, wollen wir im ersten Schritt zum Jahreswechsel dieses Keyfeld mit einer eindeutigen ID füllen, ohne Inhalt nur fortlaufend.
(Zweiter Schritt ist der Umstieg auf eine SQL-Tabelle mit Auto-Increment, aber jetzt noch kein Thema).
Die ID soll auch mit einer Prüfziffer versehen werden.

Die Frage ist, welche Variante am sinnvollsten ist.

Ich tendiere zu einer Prozedur, die eine Keytabelle oder eine SQL-Sequence (oder einen Datenbereich?) ausliest und die ID mit generierter Prüfziffer zurückgibt.

Sind Sequenzen zu empfehlen? Habe noch keine Erfahrung damit.
Und wie vermeide ich am besten Kollisionen beim Zugriff auf eine Keytabelle? Oder ist der gute alte Datenbereich die beste Lösung?

Danke im Voraus für Eure Meinungen.

[Allrounder]

Danke schon einmal für die Antworten.

@kuempi:
Wie Dieter Bender schon beantwortet hat, brauche ich eine eindeutige Referenz u.a. zur Verknüpfung mit anderen Tabellen.

@DBender:
Genau das war das Problem. Der Inhalt des Keyfeldes hat sich geändert und jetzt laufen wir Gefahr, doppelte Keys zu produzieren. Deshal die Umstellung auf eine ID ohne Inhalt.

Ich tendiere auch zur Key-Tabelle, wobei ich im Moment noch keinen Plan habe, wie ich die generierten IDs "feinkörnig" und wasserdicht vergebe. Datum/Zeit/Jobnummer reicht nicht aus, da mehrere IDs in der gleichen Sekunde benötigt werden.
Die Idee mit dem Pool von n IDs gefällt mir schonmal gut.

Ich mache mich mal an die Arbeit, bin aber für weitere Anregungen offen.

[BenderD]

Hallo,

ich würde da einfach fortlaufende Nummern nehmen (Bigint, das reicht bis zur Rente).
- Keytabelle anlegen mit Feldern Schemaname, Tablename, Keyfeld, Maxkey
- Standardfunktion
Bigint getKey/schema, Table)
erhöht maxkey um 1 und gibt maxkey zurück (exakt arbeiten mit Sperren, damit keine lock Konflikte entstehen)
wenn man blocken will, zählt man BlockSize drauf und gibt nächsten freien im Block zurück, bis Block erschöpft, dann wieder erhöhen.

mfg

Dieter Bender

PS: der Unterschied zu Autoinc ist auch, dass man den Key direkt kennt, unabhängig von Rekord Löffel Ekzem etc.

Danke schon einmal für die Antworten.

@kuempi:
Wie Dieter Bender schon beantwortet hat, brauche ich eine eindeutige Referenz u.a. zur Verknüpfung mit anderen Tabellen.

@DBender:
Genau das war das Problem. Der Inhalt des Keyfeldes hat sich geändert und jetzt laufen wir Gefahr, doppelte Keys zu produzieren. Deshal die Umstellung auf eine ID ohne Inhalt.

Ich tendiere auch zur Key-Tabelle, wobei ich im Moment noch keinen Plan habe, wie ich die generierten IDs "feinkörnig" und wasserdicht vergebe. Datum/Zeit/Jobnummer reicht nicht aus, da mehrere IDs in der gleichen Sekunde benötigt werden.
Die Idee mit dem Pool von n IDs gefällt mir schonmal gut.

Ich mache mich mal an die Arbeit, bin aber für weitere Anregungen offen.

[KingofKning]

Hallo,


PS für die Ketzter, die ansonsten meine Sympathie genießen: Keyfelder ohne semantischen Inhalt haben den Vorteil, dass bei Änderung Referenzen erhalten bleiben (im Beispiel: Zusammenfasssung zweier Aufträge zu einem)

Was heißt bitteschön semantischer Inhalt? Also ein Keyfeld ohne Inhalt gibt es für mich nicht. Entweder es steht was drin was auch immer oder es ist leer. Leere Felder ergeben aber keinen Sinn für einen Zugriffs-Schlüssel.

Kann ja sein das ich altmodisch bin aber der Formulierung konnt ich nicht wirklich folgen.

Gruß
Gregor

[Allrounder]

@DBender:
Danke für den Fahrplan, so in etwa hatte ich mir das vorgestellt. Das Blocken lass ich erst einmal, aber auf den Rest werde ich mich jetzt stürzen.

@KingofKning:
Ich hatte auch schon die Befürchtung, dass mich niemand versteht, wenn ich Keyfelder ohne Inhalt will. Klar ist eine fortlaufende Nummer auch Inhalt. Mit Inhalt meinte ich verschlüsselte Daten (Auftragsnummer, Jahr, Status, was auch immer...), die immer wieder Probleme machen, wenn sich an den Daten etwas ändert, z.B. Feldlänge.

[BenderD]

@KingofKning: ohne semantischen Inhalt meint: mit Inhalt, ohne Bedeutung (siehe auch unter Semantik in Wikipedia), manchmal nennt man sowas auch Kunstkeys.
@Allrounder: auf meiner Open Source Seite ist da ein Beispiel als SQL Procedure und im MM gabs da auch mal einen Artikel von mir dazu.

Dieter Bender

Was heißt bitteschön semantischer Inhalt? Also ein Keyfeld ohne Inhalt gibt es für mich nicht. Entweder es steht was drin was auch immer oder es ist leer. Leere Felder ergeben aber keinen Sinn für einen Zugriffs-Schlüssel.

Kann ja sein das ich altmodisch bin aber der Formulierung konnt ich nicht wirklich folgen.

Gruß
Gregor

[Allrounder]

Habe ich schon entdeckt. Das ist genau das, was ich brauche, super.

Eine Frage noch:
Die UDF GET_KEY schreibt erst eine neue, um eins erhöhte ID und liest diese im nächsten select-Statement aus und gibt sie zurück.
Gibt die UDF nicht den falschen Wert zurück, wenn ein zweiter Update (Zweiter UDF-Aufruf) erfolgt, bevor der select durchgeführt ist?

[BenderD]

das ganze muss unter Commit laufen (was es bei mir immer tut), dann bleibt der Satz gesperrt bis zum Ende der Transaktion. Wenn du in der Applikation kein Commit hast, kannst du das auch als Service Programm mit embedded SQL bauen, dem Service Programm eine eigene benamte ACTGRP verpassen und in der Function selber commit sagen.
Das schreiben vor dem lesen ist ein einfacher Weg um einen Deadlock durch die Eskalation von Sperren zu vermeiden.

B*D

Habe ich schon entdeckt. Das ist genau das, was ich brauche, super.

Eine Frage noch:
Die UDF GET_KEY schreibt erst eine neue, um eins erhöhte ID und liest diese im nächsten select-Statement aus und gibt sie zurück.
Gibt die UDF nicht den falschen Wert zurück, wenn ein zweiter Update (Zweiter UDF-Aufruf) erfolgt, bevor der select durchgeführt ist?

[Allrounder]

das ganze muss unter Commit laufen (was es bei mir immer tut), dann bleibt der Satz gesperrt bis zum Ende der Transaktion. Wenn du in der Applikation kein Commit hast, kannst du das auch als Service Programm mit embedded SQL bauen, dem Service Programm eine eigene benamte ACTGRP verpassen und in der Function selber commit sagen.
Das schreiben vor dem lesen ist ein einfacher Weg um einen Deadlock durch die Eskalation von Sperren zu vermeiden.

B*D

Die Tabelle ist erstellt, die UDF auch. Ein direkter erster Testaufruf der UDF embedded SQL aus RPG(OPM) hat prima funktioniert, die ID wird fortgeschrieben. Sorgen macht mir nur noch der Härtetest, mehrere zeitgleiche Zugriffe.

Als UDF-Neuling weiß ich nicht, ob die UDF in einer Transaktion läuft. Das Commit am Ende der UDF wird vom Navigator abgeblockt. Service-Programme habe ich bisher vermieden, weil ich noch keine Erfahrung damit habe. Würde eine eigene ACTGRP heißen, dass die UDF immer höchstens einmal aktiv ist?

[BenderD]

Hallo,

die Variante mit Blockweisem ziehen der Keynummern (immer 50 auf einmal hochaddieren) ist im absoluten Highperformance Test bewährt (bis zu 30 Batchjobs laufen parallel und bringen die Kiste mit allen Prozessoren zum qualmen.
So wie das jetzt erstellt ist, läuft die UDF in der Transaktion des aufrufenden Programmes, sprich: wenn selbiges ohne Commit arbeitet, funzt das nicht (dann bleibt der Satz gesperrt und es kann nur einer und am Ende des Jobs kommt dann ein Rollback.
Bei der Serviceprogramm Variante bewirkt die benamte Activation Group, dass das SRVPGM einen eigenen Commit Scope bekommt und dann macht man in dem SRVPGM den Commit und das drumherumliegende Programm hat da nichts mit zu tun.

D*B

Die Tabelle ist erstellt, die UDF auch. Ein direkter erster Testaufruf der UDF embedded SQL aus RPG(OPM) hat prima funktioniert, die ID wird fortgeschrieben. Sorgen macht mir nur noch der Härtetest, mehrere zeitgleiche Zugriffe.

Als UDF-Neuling weiß ich nicht, ob die UDF in einer Transaktion läuft. Das Commit am Ende der UDF wird vom Navigator abgeblockt. Service-Programme habe ich bisher vermieden, weil ich noch keine Erfahrung damit habe. Würde eine eigene ACTGRP heißen, dass die UDF immer höchstens einmal aktiv ist?