PrimaryKey in der "richtigen" Reihenfolge erzeugen

[hoika]

Hallo #,

ich habe eine Tabelle (Tab1) ohne PrimaryKey -> Schande über mich.
Das will ich jetzt nachholen, also ein Feld ID (Integer) und eine Generator (G_Tab1) angelegt.
Der PK soll dabie auch die Insert-Reihenfolge der Datensätze anzeigen
und das möglichst auch für die alten Datensätze.
Dafür hätte ich bereits ein Feld "Datum".

Wie bekomme ich es hin, dass mit einem (!) SQL-Befehl die Datensätze ihre ID
in der Reihenfolge des Datums-Feldes bekommen.
Problem ist, dass es Datensätze mit identischem Datum gibt.

Also:
Tab1
Datum
01.03.2000
01.01.2000
01.02.2000
01.02.2000

Ziel ist
ID Datum
4 01.03.2000
1 01.01.2000
2 01.02.2000
3 01.02.2000

Wie bekomme ich das hin?

Bisher:
update tab1 set id =gen_id(g_tab1,1)
where id is null

Hier wird aber die Reihenfolge nicht berücksichtigt.


#Update:#
Da bin ich aber ziemlich überrascht.
update tab1 set id =gen_id(g_tab1,1)
where id is null
order by datum

Ich wusste nicht, dass das geht.


Danke

[HHennig]

Hallo,
versuche doch mal Folgendes:

Code:

update tab1 set id =gen_id(g_tab1,1)
where id is null
order by RDB$DB_KEY

RDB$DB_KEY ist ein interner, eindeutiger DB-Key, den Firebird IMMER mitführt und der meines Wissens auch bei Deletes nicht wiederverwendet wird. Sollte also wirklich der Insert-Reihenfolge entsprechen.

[p80286]

Warum zum ***** wird beim Design von DBs bzw. Tabellen immer so herum getrickst, als wäre Plattenplatz nur mit Gold aufzuwiegen. Wenn man unbedingt eine "InsertReihenfolge" braucht, dann nutzt doch einen Timestamp! ein(Primary)Key ist nur dafür da einen Datensatz eindeutig zu adressieren. Falls er zufällig mit der "InsertReihenfolge" übereinstimmt, ist das ja sehr schön, aber das ist nichts auf was man sich verlassen könnte.

Gruß
K-H

[hoika]

Hallo,

beschwer Dich bei meinem Vorgänger !!! ;(
Ich muss das hier nur zurechtbiegen.

Das mit dem rdb$key hatte ich auch schon mal gelesen,
aber ist der nicht nur zur Laufzeit der Query gültig?
Da war doch irgendwas *in alten Unterlagen kram*.

Das mit dem InsertDateTime kann ich nur bedingt verwenden.
Ich brauche die tatsächliche Insert-Reihenfolge,
um z.B. zu erkennen, ob am Rechnerdatum rumgezaubert wurde.


Danke


Heiko

[mkinzler]

Mit der wirkliche Reihenfolge wird es schwierig werden, da es in einer Menge ja keine Odrnung gibt. Im Besten Fall bekommst Du die Datensätze in der Reihenfolge der Datei, die wenn es keine Löschungen gab, der Einfügereihenfolge nahe kommen sollte.

[Dejan Vu]

hoika schrieb, das es den Erstellungszeitpunkt gibt, den er gerne dafür verwendet hätte.

Ich vermute, das es hierbei um Kosmetik geht, was ich nachvollziehen kann.

Unter keinen Umständen würde ich mich jedoch darauf verlassen, das die Datensätze in der chronologischen Reihenfolge auch in Zukunft eingefügt werden. Einfach (oder kompliziert) ausgedrückt: A.PK > B.PK gdw. A.CreationDate>B.CreationDate. Das ist erstens redundant und zweitens gefährlich.

Das mag heute gültig sein, aber irgendwann werden vielleicht Datensätze nachträglich eingeführt, oder das Datum wird verändert, aus welchen Gründen auch immer. Stell dir den PK als anonymen und nichtsprechenden Identifikator vor. Nicht mehr, aber auch nicht weniger.

Willst Du eine totale Ordnung über den Erstellungszeitpunkt auf den Daten aufbauen, verwende einen zweiten Generator, oder eben den Zeitstempel (falls dieser eine totale Ordnung zulässt).

[hoika]

Einspruch

Ich erkenne eine Manipulation,
wenn ich z.B. folgendes sehe

Id 1000 Datum 1.1.2000
Id 1001 Datum 1.1.1999
Id 1002 Datum 2.1.2000

Ich erkenne, dass das Datum mal zurückgestellt war.

Und genau das ist mein Ziel.


Heiko

[Dejan Vu]

Hmmm. Das ist ein Grund.
Aber diese Manipulation erkennst Du nicht:
Id 1000 Datum 1.1.2000
Id 1001 Datum 1.1.2000 // war aber eigentlich 2.1.2000
Id 1002 Datum 2.1.2000

Und diese auch nicht:
Id 1000 Datum 31.12.1999
Id 1001 Datum 31.12.1999 // <-- war eigentlich 1.1.2000
Id 1002 Datum 2.1.2000

Ich glaube, um Manipulation sicher zu erkennen, müsstest Du schon andere Maßnahmen ergreifen. Vorausgesetzt, man kommt nicht direkt an die DB ran. Dann würde ich einen UPDATE-Trigger einbauen, der die Änderungen in einer separaten Tabelle protokolliert. Alle Änderungen. Mit Zeit. Und wenn Du den User zufällig hast, den gleich mit

Aber vielleicht reicht es bei Dir ja, wie Du beschrieben hast. Dann wäre das wirklich ein Grund, diese 'kosmetische' ID-Vergabe so durchzuziehen, Denk aber nicht daran, das Du auch gelöschte Daten erkennst (eine ID fehlt). Das passiert nämlich auch dann, wenn die Transaktion durch ein ROLLBACK nicht erfolgreich gespeichert wurde. Sollte zumindest.

[hoika]

Hallo,

du hast Recht.
Alles erkennt man nicht.
Aber fast alles reicht mir.

Das mit dem Generator und Rollback kenne ich, is doof aber is halt so.

Danke.

[Dejan Vu]

Eben, immer die einfachste Lösung nehmen. Würde ich dann auch so machen.