SQLite Daten aus SQLite DB in andere SQLite DB importieren

[godi]

Hallo,

ich möchte bestimmte Werte aus einer bestehenden (fremden) SQLite Datenbank in eine andere (meine) Importieren.
Dazu habe ich das Schema von meiner DB im Temp-Bereich nochmals erstellt die fremde DB an meine angehängt
und die Werte von der fremden DB aufbereitet so dass sie zu meiner Struktur passen und in die Temp-DB kopiert.

Soweit funktioniert schon mal alles.

Jetzt sollten noch die Primärschlüsseln angepasst werden (damit sie sich nicht mit denen aus meiner DB überschneiden) und danach könnte ich ja die Werte in meine DB kopieren.

Da bin ich mir jetzt nicht sicher wie ich das umsetzen soll.
1) Wenn ich die ID (PrimaryKey) in der TempDB einer Tabelle so erhöhen will das ich keine Überschneidungen mit den ID's in der Ziel Tabelle habe,
dann habe ich bei der Update query das Problem dass ich hier doppelte PrimaryKeys habe.
zB. Eine Tabelle hat 20 Zeilen => ID soll von 1 auf 10 => ID 10 gibt es schon => Error doppelter PrimaryKey!
Der Order by ID asc/desc funktioniert in der Update query irgendwie nicht.
Aber damit sollte es ja möglich sein oder?

2) Habe ich manchmal "Löcher" in den ID's. ZB auf 500 folgt 800 oder nur jede zweite ID (1,3,5,...) da ja nicht alle Daten importiert werden.
Soll ich diese Löcher stopfen oder einfach ignorieren?
In einer Tabelle sind über 2Millionen Zeilen => das würde lange dauern. 😉
Platz in einem Integer sollte ja genügend sein (bei 8 Byte 2^63-1 oder?)
Soviele Daten werden eher nur beim ersten Import übertragen.
Weiters werden dann nur noch neu hinzugekommene Daten übertragen.

3) Ist mein Weg über die Temp-DB überhaupt richtig?
Oder würde es anders einfacher gehen?


godi

 

[OlliL]

Willst du das ganze rein auf SQL-Ebene lösen? Wolltest du einfach alle Daten so modifizieren, das du mit einem INSERT INTO .... (SELECT * FROM ....); auskommst? Wenn das wirklich nötig ist, schalte alle Foreign Keys der alten Tabellen in deineri Temp-DB ab, und ändere im ersten Rutsch alle Schlüssel auf Werte welche weder in deiner DB noch in der Temp-DB vorkommen, und auch nicht zukünftig vorkommen werden (also z.B. id = id + 1000000). Und danach setzt du dann deine Schlüssel so wie du sie brauchst. Verstehst was ich meine?

Aber...

Schreibe doch ein kleines Programm, mit welchem du dir die zu migrierenden Datensätze liest, und in deine neue Tabelle einfügst mit deinem eigenem Primärschlüssel. Sehe das Problem nicht so ganz?

 

[godi]

Hallo,

Willst du das ganze rein auf SQL-Ebene lösen? Wolltest du einfach alle Daten so modifizieren, das du mit einem INSERT INTO .... (SELECT * FROM ....); auskommst?

Ja genau so habe ich es mir vorgestellt.
Ich denke das ist das schnellste oder?

Wenn das wirklich nötig ist, schalte alle Foreign Keys der alten Tabellen in deineri Temp-DB ab, und ändere im ersten Rutsch alle Schlüssel auf Werte welche weder in deiner DB noch in der Temp-DB vorkommen, und auch nicht zukünftig vorkommen werden (also z.B. id = id + 1000000). Und danach setzt du dann deine Schlüssel so wie du sie brauchst. Verstehst was ich meine?

Ja verstehe was du meinst.
Jedoch wenn ich die Foreign Keys abschalte dann gehen ja meine ganzen Referenzen verloren...

Ich habe mir das mal so vorgestellt:

UPDATE Exercises SET ExerciseID = ExerciseID + (
SELECT case when max(m.rowid) isnull then 0 else
case when max(t.rowID) - min(t.rowID) < min(t.rowID)  - max(m.rowID) then max(m.rowID)-min(t.rowID) else
case when max(m.rowID) > max(t.rowID) then max(m.rowID) else max(t.rowID) end -min(t.rowID) +1
end end as offset from main.exercises m, temp.exercises t);

Da habe ich nur einen Update Aufruf pro Tabelle und im schlechtesten Fall ist in der Zieltabelle nur eine Lücke von dem Abstand zwischen kleinster id und größter id -1 (id von der Temp Tabelle).

Jedoch ist bei Anwendung auf meine Testdatenbank (mit ca 20.000 Zeilen in der größten Tabelle) dies doch sehr langsam. t > 60s.

Aber...

Schreibe doch ein kleines Programm, mit welchem du dir die zu migrierenden Datensätze liest, und in deine neue Tabelle einfügst mit deinem eigenem Primärschlüssel. Sehe das Problem nicht so ganz?

Ich denke das dies noch langsamer werden wird wenn da Millionen von Objekten erzeugt werden müssen.

godi

 

[OlliL]

Reden wir von einer permanenten Migration oder einer einmaligen Geschichte?
Sind Alt- und Neu-Applikation zu dem Zeitpunkt offline oder läuft irgendwas von beidem parallel noch und man kann keinen gesicherten Zustand annehmen?
Hast du die Foreign-Keys mit Cascade, so das du durch das Update auf Tabelle A, den neuen Key in alle weiteren Tabellen automatisch durchziehst?

Wenn einmalig: Warum ist Zeit so extrem wichtig?
Wenn beides offline: Einmalig die maximale ID ermitteln und diese als Konstante verwenden - erleichtert das UPDATE ungemein. Generell sollte (wenn Zeit so relevant ist) ein update mit der Konstante und abgeschalteten Keys auf alle Tabellen wesentlich schneller sein als ein einzelnes Update auf die Haupttabelle und durchziehen der ID via Foreign Keys. Ich kenne die Interna von SQLite nicht, aber viele RDBMS arbeiten grundsaetzlich erstmal ohne Keys schneller (da Keys immer zusaetzliche Ueberpruefungen bedeuten) und gerade im UPDATE ist man mit Stichwort bulking x mal schneller als wenn er für jede Zeile einzeln die entsprechenden referenzierten Zeilen raussucht und diese updated... und das mit jeder Zeile in deiner Haupttabelle... enorm viele Zugriffe.

Überlege was abgeht... du machst ein Update auf eine Zeile in deiner Haupttabelle, er muss nun alle verknüpften Tabellen ermitteln, und in diesen dann die Datensätze selektieren welche den gleichen Fremdschlüsselwert haben. Diese muss er dann geziehlt anpassen.

Losgelöste UPDATE tabelle SET ID = ID + 100000; sind wesentlich fixer.

Danach kannst du ja zur Sicherheit die Keys wieder anschalten um sicher zu gehen das die Daten noch konsistent sind.

 

[godi]

Reden wir von einer permanenten Migration oder einer einmaligen Geschichte?
Sind Alt- und Neu-Applikation zu dem Zeitpunkt offline oder läuft irgendwas von beidem parallel noch und man kann keinen gesicherten Zustand annehmen?
Hast du die Foreign-Keys mit Cascade, so das du durch das Update auf Tabelle A, den neuen Key in alle weiteren Tabellen automatisch durchziehst?

Wenn einmalig: Warum ist Zeit so extrem wichtig?

Naja Zeit ist nicht so wichtig, es sollte halt keine Stunde dauern. 😉
Beide Datenbanken befinden sich lokal auf dem Rechner also Offline.
Notfalls ist es sicher noch möglich zu überprüfen ob das andere Programm auch ausgeführt wird.
Da aber nicht dauerhaft Daten in die DB geschrieben werden und sowieso selektierte Daten übertragen werden sollen ist es egal ob das andere Programm geöffnet ist und somit ein gesicherter Zustand vorhanden.

Ich habe mir das so vorgestellt, dass der Benutzer aus einer Liste auswählen kann welche Daten übertragen werden sollen. Quasi manuelle Synchronisation. Also würde nur beim ersten mal "Synchronisieren" die große Menge an Daten anfallen. Bei der nächsten Synchronisation wäre das Datenaufkommen schon viel geringer.

Die Foreign-Keys habe ich so erstellt:

FremdID INT NOT NULL 		REFERENCES FremdTabelle(FremdID) ON DELETE RESTRICT ON UPDATE CASCADE

und Pragma foreign_keys = on;

Vielen Dank für deine ausführliche Antwort!
Ich bin noch am einarbeiten in DB bzw versuche ich zur Zeit mein erstes "richtiges" Java Programm zu entwickeln. 🙂