Hi zusammen
@TigerLily
Zitat:
PRAGMA foreign keys): Bei einem Import gibt es das Problem, dass uU Datensätze importiert, die eine Referenz auf einen Datensatz besitzen, der noch nicht importiert wurde. Wenn diese Referenz als foreign key abgebildet ist, gibt es einen Fehler. Wenn man aber weiß, dass alle Referenzen nach dem Import erfüllt sind, kann man diese foreign keys deaktivieren. Das kann man für einzelne foreign keys machen, einzelne Tabellen oder die ganze Datenbank (=PRGAMA foreign_key OFF). Und dreht es nach dem Import wieder auf.
Um mal 'alle Klarheiten zu beseitigen': die Datenbank, von der hier die Rede ist, ist leer, enthält also aktuell keine Daten. Diese werden von meinem Programm von Festplatte/direkt ab Scandisc in Form von Raw-Bildern eingelesen(Pathlist) und in einer bestimmten Reihenfolge in die
DB geschrieben.**
Das heisst: von der zu erstellenden SQLite-
DB müssen keine Daten aus
MySQL übernommen werden, und deshalb ist das 'ATTACH' hier für mich erstmal nicht von Bedeutung - was aber nicht heisst, dass ATTACH grundsätzlich unwichtig für mich wäre, denn spätestens, wenns darum geht, Backups zu erstellen oder einzulesen, hat ATTACH sehr wohl Bedeutung. Dasselbe dürfte auch für die ForeignKeys gelten. Mein
DB-Modell besteht gewissermassen aus 2 Zweigen, von
MySQL Workbench "Layer" genannt.
Zentral ist dabei die Bildtabelle. Sie enthhält Spalten für das Rohbild, ein Thumbnail, eine Bitmap, ein Jpeg und eine FolderID.
Anschliessend wird ein Insert auf die Describetabelle gemacht und der PK der Bildtabelle als Fremdschlüssel eingefügt.
In diesem Layer gibt es noch eine Kategorientabelle, die mit der Desribetabelle über eine n:m-Beziehung verknüpft ist. Bevor überhhaupt mit einem Insert begonnen werden kann, muss diese Tabelle Daten enthalten, ansonsten bricht die Transaktion ab, da diese Tabelle den PK für den FK der Zwischentabelle liefert.
Es kann also keinen FK geben, der auf einen noch nicht vorhandenen PK verweist. Zumindest für diesen soeben beschriebenen ersten Zweig nicht.
Spannender wirds beim 2. Zweig. Dieser besteht zentral aus einer
HTML-Tabelle, welche über eine Zwischentabelle mit der Bilddescribetabelle in einer n:M-Beziehung verbunden ist. Diese
HTML-Tabelle wird vorerst nicht editiert; es gibt also hier keinen Insert und damit vorerst keinen mit der Bilddescribetabelle verbundenen Datensatz. Dieser wird erst zur Progammlaufzeit erstellt.
Sinn des Programmes ist es, zur Laufzeit eine (oder mehrere)
HTML-Seiten zu erstellen und dieser dann per Drag&Drop bestimmte Bilder zuzuweisen. Das ist dann auch der Zeitpunkt, an dem die benötigten PK und FK erstellt und zugewiesen werden.
Zitat:
Wenn man aber weiß, dass alle Referenzen nach dem Import erfüllt sind,...
Das, fürchte ich, ist nur dann gefahrlos, wenn die Daten aus einer
DB mit gleicher Struktur stammen, also eben etwa aus einem Backup.
**Die in meinem ersten Post gezeigte 'Satelliten"-
DB soll pro Kategorie die RAW-Bilder und eine Bitmap dieser Rawdaten enthalten. Ziel ist es, diese Daten nicht in der "Mutter"-
DB vorzuhalten, sondern extern auf beliebigen Laufwerken. Der Grund: die RAW-Bilder sind je nach Kamera zwischen 10 und 24 Megabyte gross, die entsprechenden Bitmaps in der Originalgrösse dreimal grösser.
Gruss
Delbor