Primary Key und 1:N Relationen

Hallo,

bin wahrlich kein Experte in Sachen Datenbanken, daher mal folgende Frage:

Ich habe eine 1:N Relation, im Java Code hat ein Objekt viele Referenzen auf Zeitpläne (repeat).



Nun sind diese Repeats alle recht trivial, was momentan auch mein Problem ist, da Ich nicht garantieren kann das es diesen Repeat nicht schon mal in der gleich Form bereits in der Tabelle repeat gibt. Füge Ich nun einen repeat in die Tabelle ein müsste Ich für meine relation den primary key des repeat kennen.
Einen Insert über SQLDatabase#insert liefert mir doch leider nur die ROW ID was mir nicht weiterhilft, auch einen Trigger habe Ich schon versucht zu schreiben, doch auch hier habe Ich das Problem das Ich bei dieser Relation immernoch nicht den PRIMARY KEY in der schedule_repeat_relation kenne.

Hier mein trigger versuch der leider das Problem nicht löst:




Also, man kann das Problem grob darauf zusammen-stutzen das Ich nicht weiß wie Ich an den Primary Key eines Objektes kommen kann ohne das der Eintrag in der Tabelle eindeutig ist.
Ich brauche also Foreign Keys, was SQLite leider nicht unterstützt. Die einzige lösung die mir momentan einfällt ein Dummy Feld in der Tabelle repeat einzufügen welches Ich z.b mit den Nanosekunden fülle, und mir diese merke um danach einen entsprechenden Primary key ermitteln zu können der auch wirklich zu dem Eintrag gehört.

Gibt es Ideen hierzu ? Oder stehe Ich total auf dem Holzweg ?

Danke für Anregungen,
Mac

Ja.


Ein "SELECT MAX (_id) from repeat" liefert mir den Primary Key!

- Mac

Du weist schon das rowID != primary key ist ?

PS: Wo steht das Ich ein Problem mit dem Updaten der DB habe ?

— geändert am 12.02.2010, 10:09:58

Erst ab SQLite 3.6.22

Überlege mal was bei einem delete passiert ;)

Es geht nicht um das direkte delete, nur das ein delete die RowID ändert nicht den Primary Key des nächsten Inserts!

Daher RowID != Primary Key

Oder:

a Insert = (rowID = 0) (PK = 1)
a delete
a insert = (rowID = 0) (PK = 2)

Wo kann Ich so etwas nachlesen ?

Thx, ich hab wieder was gelernt

Das beißt sich dennoch ein wenig mit der API die einen long liefert. Ist das so gewählt damit bei eigenen Primary Key der größtmögliche Zahlenraum zur Verfügung steht ?