Das deutsche Python-Forum

Hallo!

Ich schreibe eine Anwendung die Daten u.a. in Many-to-many-Relationships in einer SQLite-Datenbank speichert. Diese Anwendung wird maximal von einer Handvoll Nutzern genutzt und beinhaltet maximal einige tausend Einträge. Von der Funktionsweise ist sie vergleichbar mit einer Verwaltung für Bücher oder Musikalben. Diese Datenbanken sollen online miteinander synchronisiert werden.

Ich nutze zur online-Synchronisation eine MySQL-Datenbank und die Synchronisation funktioniert bereits soweit, dass neue, veränderte und gelöschte Einträge grundsätzlich synchronisiert werden können, allerdings noch nicht, dass korrekt zwischen neu erstellten, gelöschten und veränderten Daten die mit dem Löschen von Association-Daten (bei Many-to-many) verbunden sind, korrekt unterschieden wird.

Ich nutze für die Umsetzung SQL Alchemy 2. Meine Tabellen haben alle selbst generierte Unique-IDs und es wird jeweils der Zeitpunkt der Erstellung und Veränderung erfasst.

Da ich bisher keine für mich hilfreichen Informationen finden konnte, bin ich nun unsicher, wie kompliziert und aufwendig es ist, dass die Datenbanken korrekt synchronisiert werden, was genau ich dafür beachten muss und ob sich das gut mit SQL ALchemy 2 umsetzen lässt, oder es bereits bessere fertige/andere Lösungen dafür gibt.

Auf der Suche bin ich bsw. auf rqlite oder litesync gestoßen.

Macht es Sinn, das mit SQL Alchemy und zentraler MySQL-Datenbank umzusetzen und worauf müsste ich da achten oder gibt es bereits (einfachere/verlässlichere) Lösungen?

Freu mich über Tipps!

Warum arbeiten die lokalen Installationen mit einer eigenen Datenbank und verwenden nicht gleich die Datenbank, die du zum Synchronisieren verwendest?

Unter anderem weil es wichtiger ist, dass das Programm unabhängig einer Internetverbindung genutzt werden kann, als dass die Daten immer synchron sind.

Wie willst Du Konflikte auflösen? Das geht um so schwieriger, wenn Du auch noch erlaubst, dass Daten geändert oder gelöscht werden.
Eigentlich geht das nur, wenn alle Operationen idempotent ist und die Reihenfolge vertauschbar.
Bedeutet also eine ganz andere Denkweise, als Du das bisher hast.

Es ist ausreichend, wenn bei unterschiedlichen Einträgen derjenige mit dem jüngeren Veränderungsdatum erhalten wird und ansonsten die Unterscheidung zwischen gelöschten und neuen Einträgen funktioniert. Das sollte doch nicht so schwierig sein?

Mir gehts darum, zu erfahren, worauf es dabei ankommt oder vielleicht schon verwendbare Lösungen bestehen.

Bei einer eigenen Umsetzung würde ich vom Ansatz her entweder über Erstellungs/Änderungs/Synchronisationszeitpunkte gehen und/oder Listen mit den neuen/veränderten/gelöschten Einträgen. Aber ich bin ja sicher nicht der erste damit und möchte das Rad ungern neu erfinden.

Genau, wenn Du nachverfolgen willst, wann welche Aktion durchgeführt worden ist, brauchst Du ein Protokoll. Das mußt Du also mit speichern und für die Rekonstruktion des aktuellen Zustandes an Deine zentrale Datenbank übertragen. Denn wenn Daten einfach fehlen, dann weißt Du nicht ob A den Eintrag gelöscht hat, bevor B ihn neu angelegt hat, oder ob B den Eintrag geändert hat und dann A ihn gelöscht hat.
Wenn Du aber so ein Änderungsprotokoll hast und die eigentlichen Einträge, dann hast Du doppelte Datenhaltung. Das macht die Sache kompliziert und es besteht die Gefahr von Inkonsistenzen. Deshalb, wenn möglich die Datenbank gleich so zu stricken, dass es nur das "Änderungsprotokoll" gibt. Mit dem richtigen Datenbankdesign sind nämlich Abfragen auf den aktuellen Zustand damit ebenso einfach möglich.

Wie sähe so ein "richtiges Datenbankdesign" denn aus?

Ich habe jetzt folgende Idee: ich könnte grundsätzlich Einträge in der zentralen Onlinedatenbank, die in der lokalen nicht vorhanden sind als neu annehmen. Lokale Daten, die lokal gelöscht werden, ohne dass sie zuvor schon synchronisiert waren, könnten lokal normal gelöscht werden, und für bereits synchronisierte Daten ein Eintrag mit der selben ID erhalten werden, der einfach eine Markierung beinhaltet, dass er gelöscht wurde. Die zentrale Datenbank würde dann diese Einträge einfach aufbewahren und die lokalen Datenbanken diese Einträge dann nicht übernehmen, ebenfalls löschen oder eventuell auch selbst entscheiden, ob sie sie behalten wollen. Sollten die lokalen Daten, die zentral als gelöscht markiert wurden ein jüngeres Veränderungsdatum haben, könnten diese sogar wieder als normale Einträge registriert werden. Das erscheint mir eine recht einfache und praktikable Lösung zu sein. Hab ich da was übersehen?