Zwei SQLite Datenbanken synchronisieren - Strategie

[Grolle]

Hallo,

was ist die beste Strategie, um 2 SQLite Datenbanken (1 Tabelle) zu synchronisieren. Jeder Datensatz hat momentan einen created und updated timestamp. Ist es sinnvoll für eine Synchronisation noch einen Hash über jeden Datensatz anzulegen? und wie könnte dann eine Synchronisation per SQL aussehen?

Vielen Grüße ...

[s.h.a.r.k]

ein hash wäre wohl am sinnvollsten imho, da du ja alle daten verändern kannst, ohne die zeitstempel zu veränden

[Grolle]

Hi,

Zitat von s.h.a.r.k:

ein hash wäre wohl am sinnvollsten imho, da du ja alle daten verändern kannst, ohne die zeitstempel zu veränden

bei einem Update wird natürlich immer der (update)Zeitstempel gesetzt (ich gehe jetzt nicht von einem direkten ändern in der Datenbank aus, sondern nur über mein Programm).

Viele Grüße ...

[s.h.a.r.k]

Wenn du garantieren kannst, dass die Zeitstempel bei jedem Update auch aktualisiert werden, dann kannst du das wahrlich via Zeitstempel machen. Wer sollte sonst auf die Daten Zugriff nehmen? Wenn das nicht der Fall ist, dann wäre die Idee mit dem Hash richtig.

[Grolle]

Hi,

ja, dass kann ich garantieren, jetzt fehlt mir nur noch die Synchronisation per SQL bzw. ein Ansatz dafür (beide Datenbanken sollen nach der Synchronisation auf dem aktuellsten Stand sein).

Viele Grüße ...

[Grolle]

Hi,

ich push das nochmal, da ich etwas ratlos bin. Das Problem was ich habe, dass sich in beiden Datenbanken was ändern kann. Daher habe ich ja keinerlei Anhaltspunkte, ob ein Datensatz dann ein Update geändert werden kann oder noch gar nicht vorhanden ist.

Ratlose Grüße ...

[omata]

Das größte Problem dabei sind gelöschte Datensätze. Weil dieser dann auf der anderen Seite existiert und man dann nicht weiß, ob dieser dann gelöscht oder eben aus der anderen DB übertragen werden soll.

Ich habe soetwas gelöst, indem ich ein Protokoll erstellen lasse. In diesem Protokoll steht, die Tabelle, die Änderung (I, D, U), der Zeitstempel und der PK-Inhalt). Dieses Füllen wird über Trigger realisiert, somit ist es egal, wie man die Daten ändert (per Programm oder direkt in der DB). Das Sync-Tool schaut sich dann die Logtabelle an und kann dann die nötigen Änderungen durchführen, indem eben die eigentlichen Daten aus den zugehörgen Tabellen geholt und übertragen werden.
Bei diesem Vorgehen gibt es also nur eine Sync-Tabelle und wenn später noch mehr Tabellen syncronisiert werden müssen, so ist nur ein weiterer Trigger nötig.


Edit: Bei erfolgreicher Änderung, kann die zugehörige Protokollzeile gelöscht werden. Somit entsteht kein bleibendes Datenvolumen, nur solange, bis die Syncronisation durchgeführt wurde. Kann mal eine Änderung nicht durchgeführt werden, werde alle weiteren, die mit der nicht durchgeführten Änderung in Verbindung stehen, ebenfalls nicht durchgeführt. Trotzdem sind die Änderungen weiterhin bekannt und können später (bei z.B. Korrektur der DB-Struktur) durchgeführt werden. Das ist ziemlich wichtig, weil mir das regelmäßig passiert, dass ich mal etwas an der DB verändere und es garantiert auf der Gegenseite vergesse.

[Grolle]

Hallo,

sichert der autoinc PK mir zu, das dieser selber auch nicht mehr belegt wird, wenn einmal gelöscht? Habe das gerade bei SQLite getestet und scheint so zu sein. Das löschen könnte ich ja auch innerhalb meines Programms berücksichtigen.

Viele Grüße ...

[omata]

Das hatte ich ganz vergessen zu erwähnen. AutoInc-Felder sind bei meiner Lösung nicht möglich bzw. sind doch eigentlich bei einer Syncronisation gar nicht möglich. Weil man ja keinen Wert in das Feld schreiben kann, genau das muss man aber doch, wenn der Wert von der anderen Seite kommt. Oder wie soll das gehen?
Bei so einer Lösung würde ich mich nur auf die DB selbst verlassen. Irgendetwas in einem speziellen Programm "zu wissen" ist echt tödlich, wenn man mal schnell was direkt in der DB ändern möchte.

Naja, war ja auch nur als Anregung gedacht...