Einzigartigkeit von Objekten in Server - Client sicherstellen

[*john 0]

@Leon0402 sagte in Einzigartigkeit von Objekten in Server - Client sicherstellen:

@john-0 sagte in Einzigartigkeit von Objekten in Server - Client sicherstellen:

Das ganze Vorgehen klingt nach einem Rezept für Kollisionen.

Welches ganze Vorgehen? Ein Server - Client Modell mit Offline Funktionalität? Oder die eindeutigen IDs Clientseitig zu generieren? -> Das war ja nicht in den Stein gemeißelt, sondern meine Idee. Ich freue mich auch gerne über Alternative Vorschläge!

Die IDs auf Clientseite lösen das Problem nicht! Das Problem ist, dass durch den Offline Betrieb Kopien oder konkurrierende neue Einträge entstehen können, und Du Dir darüber Gedanken machen musst wie Du diese Konflikte löst. Eine ID auf Clientseite ist dabei überhaupt nicht hilfreich, weil sie suggeriert, dass es keinen Konflikt gäbe.

Beispiel:
Die DB enthält Adressdaten mit folgendem Eintrag
Hans Mustermann
Musterstraße 2
99999 Musterdorf

Nutzer A ändert den Eintrag auf
Hans Mustermann
Musterstraße 1
99998 Musterstadt

Nutzer B ändert den Eintrag auf
Heinz Mustermann
Musterstraße 2
99999 Musterdorf

Welcher Eintrag ist denn nun korrekt? Analog besteht die Möglichkeit, dass beim offline Erzeugen neuer Einträge exakt die gleiche Problematik auftritt. Wenn der Abgleich über eine UUID erfolgt, dann gibt es keinen Konflikt, wenn der Abgleich über die Daten erfolgt, dann brauchst Du auch keine UUID.

[Swordfish]

@john-0 sagte in Einzigartigkeit von Objekten in Server - Client sicherstellen:

und Du Dir darüber Gedanken machen musst wie Du diese Konflikte löst. Eine ID auf Clientseite ist dabei überhaupt nicht hilfreich, weil sie suggeriert, dass es keinen Konflikt gäbe.

Boah wenn Leute die keinen Plan haben einfach mal die Pappm hoitn würden.

[Leon0402]

@john-0 sagte in Einzigartigkeit von Objekten in Server - Client sicherstellen:

Die IDs auf Clientseite lösen das Problem nicht! Das Problem ist, dass durch den Offline Betrieb Kopien oder konkurrierende neue Einträge entstehen können, und Du Dir darüber Gedanken machen musst wie Du diese Konflikte löst. Eine ID auf Clientseite ist dabei überhaupt nicht hilfreich, weil sie suggeriert, dass es keinen Konflikt gäbe.
Beispiel:
Die DB enthält Adressdaten mit folgendem Eintrag
Hans Mustermann
Musterstraße 2
99999 Musterdorf
Nutzer A ändert den Eintrag auf
Hans Mustermann
Musterstraße 1
99998 Musterstadt
Nutzer B ändert den Eintrag auf
Heinz Mustermann
Musterstraße 2
99999 Musterdorf
Welcher Eintrag ist denn nun korrekt? Analog besteht die Möglichkeit, dass beim offline Erzeugen neuer Einträge exakt die gleiche Problematik auftritt. Wenn der Abgleich über eine UUID erfolgt, dann gibt es keinen Konflikt, wenn der Abgleich über die Daten erfolgt, dann brauchst Du auch keine UUID.

Ich glaube du sprichst hier zwei verschiedene Thematiken an. Mir geht es nur um eine eindeutige Indendifikation der Einträge zu ermöglichen. Du schreibst in deinem Beispiel:

"den Eintrag" -> Welchen Eintrag? Woher weißt du, dass das "Der Eintrag" ist und nicht irgendein x-beliebiger ander Eintrag, der halt zufällig die selben Daten hat. Indem du eben eine ID hast, denn es gibt (wie am Anfang gesagt) keinen natural key. Es muss also eine Idenfikation geben, damit du weißt, dass irgendein Client "den Eintrag" verändert hat

Was du beschreibst sind Konflikte. Daher man hat bereits eindeutig festgestellt, dass zwei verschiedene Client zeitgleich (während sie offline waren) dieselben Daten beschrieben haben. Wie geht man damit um?

Das ist definitiv ein Problem mit vermutlich vielen Ansätzen:

• Man nimmt einfach den ersten / letzen (Don't care)
• Man fragt den Nutzer, welchen er haben möchte
• Man hat automatische oder Teil-automatische Merge Konflikt Algorithmen (siehe z.B. git)
• ....

Aber es ist ein anderes Problem und war erstmal nicht direkt meine Frage.

Daher noch mal meine Frage: Wie identifiziert man ein Objekt eindeutig in einem Multi-Client - Server Szenerario mit Offline Funktionalität. Wer generiert wann wo die dazu nötigen eindeutigen Daten (Ids)? Welche Idenfikation wird wo gespeichert?

Einige Ansätze waren:

• Der Client generiert eine eindeutige ID (per UUID). Das Objekt wird sowohl lokal als auch auf dem Server nur über diese ID identifieziert.
• Der Client generiert eine eindeutige lokale ID (z.B. Auto Increment) und kombiniert sie mit einer eindeutigen statischen Client ID, die er bei erstmaliger Registrierung bekommt. Die ID wird entweder zusammengesetzt <lokale-Id>-<Client-id> oder eben beides seperat abgespeichert auf Server Seite
• Der Client generiert eine eindeutige lokale ID (z.B. Auto Increment) und der Server generiert beim ersten hochladenen eine eindeutige globale ID, welche er dem Client mitteilt. Serverseitig wird nur nur die globale ID gespeichert, Client Seitig beides.

Zusätzlich gab es noch ein paar Ideen dazwischen. Zum Beispiel @SeppJ hatte, wenn richtig verstanden, Ansatz 2 im wesentlichen vorgeschlagen. Nur das die Client IDs partioniert werden und dann die Client ID mit der lokalen auto increment ID addiert wird (anstatt das die IDs zusammengesetzt werden).