Int-Feld nachträglich auf autoincrement setzen

[mkinzler]

Da mag es Vorkommen. Eigentlich sollte man hier keine Werte vorgeben, wenn man es aber macht, warum auch immer, könnte es zur Verwirrung führen, wenn der vorgegebene Wert ignoriert wird.

[DeddyH]

Och, da halte ich es wie Linus Torvalds:

Zitat:

If you have any great suggestions, feel free to mail me, and I'll probably feel free to ignore you.

:mrgreen:

[Hansa]

Zitat:

Zitat von mkinzler (Beitrag 1183432)

... Wird eine ID angegeben, könnte man davon ausgehen, dass diese auch verwendet wird.

Sofern sie verwendet werden KANN !! 8-) Vielleicht ist die explizit angegebene ID ja bereits vorher von einem Trigger bereits vergeben.

Die Problemtik wird richtig schön, wenn alte Datenbestände importiert werden müssen.

Angenommen, ich muss Rechnungen importieren und die zugehörigen Artikel auch. Die IDs werden Lücken enthalten usw. Verwende ich da jetzt Generatoren / aktive Trigger (ohne die alten IDs anzugeben) dann zählen die einfach dumm hoch. Sieht ja nicht so schlimm aus. :P Bei den Rechnungen, sofern es da nur Positionen gibt, da könnte das noch gehen, aber wehe die Artikel erhalten neue IDs. Dann haben die Rechnungspositionen nicht vorhanden /völlig falsche IDs. In solchen Fällen muss man die ursprünglichen IDs fast überall verwenden. Also Trigger deaktivieren. Ist erst mal alles importiert, dann sollte man auch den Trigger aktivieren, auf grössten bereits vorhandene ID + 1 setzen.

Das wurde hier zwar in Halbsätzen irgendwie angesprochen, aber nicht so richtig. :mrgreen:

[jobo]

Zitat:

Zitat von Hansa (Beitrag 1183478)

..In solchen Fällen ..

Ist es häufig ratsam, die technischen Schlüssel von den fachlichen Schlüsseln zu trennen.

Ich verfahre auch gelegentlich wie DeddyH es beschrieben hat. Das geht aber nur, wenn ich technische Interna der Implementierung kenne und gezielt ID unterhalb des Generators bzw sogar unter dessen initalem Startwert nehme.

Ansonsten sehe ich das so wie mkinzler, die Anwendung sollte sich für den Anwender transparent verhalten.

[Hansa]

Zitat:

Zitat von jobo (Beitrag 1183513)

Ist es häufig ratsam, die technischen Schlüssel von den fachlichen Schlüsseln zu trennen.

Ich verfahre auch gelegentlich wie DeddyH es beschrieben hat.

Erstens hat DeddyH zwei verschiedene Methoden beschrieben. In dem einen Fall wird der Generatorwert eben nur dann hochgezählt, wenn noch keine ID da ist. Dann bin ich echt verblüfft, dass es sogar möglich ist mit "normalen" Wörtern Verwirrung zu stiften. :mrgreen:

Was soll sich Otto-Normaluser unter einem "technischen und einem fachlichen Schlüssel" vorstellen? :shock: Oder was ist das ? "die Anwendung sollte sich für den Anwender transparent verhalten". Das sind lediglich Schlagwörter, die einem vorgaukeln, einer wisse schon was er sagt. Ich übersetze das mal so : zu jedem Datensatz gehört eine ID (könnte man "technischer Schlüssel" nennen), die der Endbenutzer allerdings weder sehen noch manipulieren soll (Transparenz ?). Im Programm selbst wird nur mit merkbaren Nummern hantiert (fachliche Schlüssel ?). Sprich : Artikel-Nr., Rechn.-Nr. usw. Man nimmt nun eine Art.-Nr. aber nicht, um sie in sämtlichen abhängigen Tabellen, z.B. Rechnungspositionen zu verwenden. Denn was passiert mit den Rechnungen, sofern sich eine Art.-Nr. ändert ?

Richtig. Im Falle, dass sich eine Art.-Nr. ändert müssen alle Rechnungspositionen angepasst werden (im Normalfall noch viel mehr). Also entkoppelt man die vermeintlich wichtige Art.Nr. vom Rest und behandelt sie als normales Feld (wie z.B. Preis, Artikel-Bez.). Macht man das so, dann braucht man aber trotzdem noch eine eindeutige Identifikationsnr. für einen Datensatz, also eine ID. Denn die ist auch dann eindeutig, wenn sich das Feld "Art.-Nr." ändert.

Jetzt wären wir beim Fall "Int-Feld nachträglich auf autoincrement setzen". Sofern das um eine ID geht, dann nützen Generatoren/Trigger zuerst mal gar nichts. Denn die ID ist ja schon vorhanden. Wie bei meinem Beispiel Importieren von Fremddaten. Der ID-Wert muss dann auf einen vernünftigen Anfangswert gesetzt werden. Erst dann kann der Trigger ohne Kollisionen aktiv werden.

So etwas hilft da auch nur halb :

Delphi-Quellcode:

set term ^;
CREATE TRIGGER Table1_BI FOR T1
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
  if (NEW.ID is NULL) then
    NEW.ID = GEN_ID(GEN_Table1_ID, 1);
END!!
set term ;^

Da wird die ID zwar nur hochgezählt, wenn die ID noch nicht bekannt ist, aber was, wenn die neu erzeugte per Insert in die Tabelle eingefügt werden soll, aber bereits da ist ? :shock:

[jobo]

Zitat:

Zitat von Hansa (Beitrag 1183516)

Was soll sich Otto-Normaluser unter einem "technischen und einem fachlichen Schlüssel" vorstellen? :shock:

Ziemlich genau das, was Du ausgeführt hast. Ich gehe davon aus, dass hier vorwiegend Entwickler und nicht Normal User unterwegs sind.

Zitat:

Oder was ist das ? "die Anwendung sollte sich für den Anwender transparent verhalten". Das sind lediglich Schlagwörter, die einem vorgaukeln, einer wisse schon was er sagt.

Transparenz ist für mich ganz allgemein, dass Außenwirkung und Geschehen übereinstimmen.
Im dargestellten Fall wäre es intransparent, wenn der Anwender eine ID vergeben kann, die manchmal 1:1 übernommen wird, manchmal aber nicht (abhängig von der Triggerlogik)

Zitat:

Ich übersetze das mal so : zu jedem Datensatz gehört eine ID (könnte man "technischer Schlüssel" nennen), die der Endbenutzer allerdings weder sehen noch manipulieren soll (Transparenz ?).

Wenn das Verhalten der technischen ID konsistent ist und diese ID für den Anwender gänzlich unerheblich ist, kann man sie auch verstecken, ohne dass ich das intransparent nennen würde.

Zitat:

Im Programm selbst wird nur mit merkbaren Nummern hantiert (fachliche Schlüssel ?). Sprich : Artikel-Nr., Rechn.-Nr. usw. Man nimmt nun eine Art.-Nr. aber nicht, um sie in sämtlichen abhängigen Tabellen, z.B. Rechnungspositionen zu verwenden.

Ja, so meinte ich das.

Zitat:

Jetzt wären wir beim Fall "Int-Feld nachträglich auf autoincrement setzen". Sofern das um eine ID geht, dann nützen Generatoren/Trigger zuerst mal gar nichts. Denn die ID ist ja schon vorhanden.

Wieso nützen die nichts? Eine ID mit definierter Eindeutigkeit ist per se unabhängig von einem Trigger / Autoincrement Mechanismus. Alle ID die schon da sind, sind per Definition bereits eindeutig.

Zitat:

Wie bei meinem Beispiel Importieren von Fremddaten. Der ID-Wert muss dann auf einen vernünftigen Anfangswert gesetzt werden. Erst dann kann der Trigger ohne Kollisionen aktiv werden.

Ob ich "regulär" Daten mittels Programmmaske erzeuge oder importiere, ist dem Trigger doch vollkommen egal.
Verwendet eine Applikation den via Trigger erzeugten Primärschlüssel (von mir zuvor technischer Schlüssel genannt) zur Darstellung von fachlichen Inhalten (z.B. die Rechnungsnummer), dann ist das ganze natürlich für die Tonne.

Genau diesem Problem galt mein Hinweis, diese Schlüssel besser von vornherein getrennt zu verwalten.

Zitat:

So etwas hilft da auch nur halb :
..

Ja, sehe ich auch so.

[p80286]

Zitat:

Zitat von Hansa (Beitrag 1183516)

Da wird die ID zwar nur hochgezählt, wenn die ID noch nicht bekannt ist, aber was, wenn die neu erzeugte per Insert in die Tabelle eingefügt werden soll, aber bereits da ist ? :shock:

Du hast genau drei Möglichkeiten,
a) alle (primärschlüssel) werden per Trigger/Sequence/autoincrement erzeugt.
b) für neue Datensätze wird eine automatische Schlüsselerzeugung genutzt, deren Minimalwert einen hinreichenden Abstand zu den existierenden Altschlüsseln hat.
c) Du läßt die Schlüssel durch ein schwarzes Loch erzeugen, darfst aber nicht vergessen, die Tageshöchsttemperatur der letzten 743 Tage von Helsinki mit in die Berechnung aufzunehmen.
Solltest Du allerdings den Kölner Pegel der Jahre 1850-1865 nutzen mußt Du naturlich die Sonnenscheindauer der ersten drei Maitage in Berlin im Jahre 1756 mit einbringen.

Gruß
K-H

[Hansa]

Ihr seid theoretische Möchtegern-Schlaumeier. :mrgreen:

Also gut, nehmen wir leere Datenbank. Mit IDs, Triggern usw. Ohne Eingriffe sitzt Generator erst mal auf 1.

Zitat:

Zitat von jobo

Ob ich "regulär" Daten mittels Programmmaske erzeuge oder importiere, ist dem Trigger doch vollkommen egal.

Gut, machen wir das mal so. Also wird in leere DB mal ein Artikel eingefügt. Der erhält dann die ID 1 und noch einer, der kriegt ID 2. Ach ja, da waren ja noch die alten Artikel, die müssen ja noch da rein, also mache ich das mal und füge Art.Nr. 123 ein, der erhält dann automatische die ID 3 (obwohl er vorher die ID 100 hatte).

Dann noch 3 neue Artikel, damit sind ID 4,5,6 weg. So weit so gut.

Verdammt, die Rechnungspositionen müssen ja auch noch rein.

Dabei gilt ja angeblich das hier :

Zitat:

Zitat von p80286

a) alle (primärschlüssel) werden per Trigger/Sequence/autoincrement erzeugt.

Klaro, das geht dann wieder so weiter, ID wird jeweils um 1 erhöht und fertig. Ansonsten werden die Rechnungspositions-Felder 1:1 übernommen. Also Menge usw.

Sieht gut aus, aber die gesamte DB ist im Eimer ! :glaskugel:

So und jetzt reichts. Wer den offensichtlichen Fehler nicht sieht, der muss sich mal mit DB-Grundlagen befassen.

[DeddyH]

Und deshalb sind (bei mir) alle PK künstliche Schlüssel, die per Trigger/Generator befüllt werden. ArtNr wäre dann frei zu vergeben, aber unique. Wenn man will/muss, kann man also die Originalnummer behalten, solange sie eindeutig ist. Aber da sie ja vorher PK war, sollte das in jedem Fall zutreffen.

[p80286]

Zitat:

Zitat von Hansa (Beitrag 1183530)

....
Dann noch 3 neue Artikel, damit sind ID 4,5,6 weg. So weit so gut.

Verdammt, die Rechnungspositionen müssen ja auch noch rein.

.....

Und wer so arbeitet, sollte vllt. den Beruf wechseln.
(ich hab im Augenblick das Vergnügen eine DB wieder so hinzubiegen, das die Schlüssel wieder passen, darum bin ich ein wenig gereizt)

Gruß
K-H