DB Abgleich

[Phoenix]

Wieso überhaupt irgendwelche Sperrlisten?

Das klingt mir danach, als würdest Du eine Logik nachprogrammieren, die die Datenbanken von sich aus schon zur Verfügung stellen. Wieso willst Du das Rad neu erfinden? Zumal Dein Rad wahrscheinlich noch nichtmal rund sein wird sondern - sorry, no offense - aufgrund Deiner offensichtlichen Wissenlücken über Datenbanksysteme, mit an Sicherheit grenzender Wahrscheinlichkeit ziemlich viereckig sein dürfte.

[Tim Henford]

ja das stimmt natürlich, aber es sieht so aus, dass ich für den Fall hier mir selbst ein Synchronisationskonzept überlegen muss, denn ich weiß nicht, ob die DB entscheiden kann, welcher Messwert von welchem Platz nun der richtige ist.
Bei Überschneidungen soll der User gefragt entscheiden, welche Werte nun die besseren sind...

Über eine schnellere einfachere Lösung wäre ich auch froh

[Phoenix]

Was hat das eine (Entscheidung welche Werte) mit dem anderen (Sperren der DB) zu tun?

[Tim Henford]

Das Sperren ist Voraussetzung für die strikt sequentielle Ordnung der Updates und Änderungen.
Sonst wurschtelt ja irgendwer irgendwann mal irgendwas dazwischen, wo keiner weiß wo es herkommt...

[mkinzler]

Zudem gibt es auch fertige Replikationssysteme für verschiedene Datenbanken.

Zitat:

Sonst wurschtelt ja irgendwer irgendwann mal irgendwas dazwischen, wo keiner weiß wo es herkommt...

Du solltest dich wirklich mal mit den Grundlagen von Datenbanken einarbeiten.

[Tim Henford]

Diese Replikationssysteme fragen meines Wissens aber nicht nach, welcher Eintrag der richtige ist und somit wird das mit der automatischen Synchronisation auch nix wirklich

[Phoenix]

Zitat von Tim Henford:

Sonst wurschtelt ja irgendwer irgendwann mal irgendwas dazwischen, wo keiner weiß wo es herkommt...

Fall zu Deinem Konzept:
1.) User A schaut in Deine Sperrliste. Findet nix.
2.) User B schaut gleichzeitig in Deine Sperrliste. Findet auch nix.
3.) User A und B fangen gleichzeitig an, die Daten zu synchronisieren.

Und jetzt schnapp Dir ein gutes Buch über Datenbanksysteme, nimm Dir zwei, drei Wochen Zeit, und frage dich dann nochmal, ob Du ein Synchronisierungskonzept selber entwickeln willst. Ich gehe jede Wette ein, dass ein selber implementiertes System eher früher als später a) in eine Deadlock-Situation rennt oder b) trotz bestmöglicher Absicherung eine Kollision zulässt.

Oder um es ganz deutlich zu sagen: Finger weg von eigenen Sperrmechanismen, sobald Du ein System benutzt dass es zum einen schon selber kann und das zum anderen auch noch besser, als Du es jemals selber implementieren könntest.

[Phoenix]

Zitat von Tim Henford:

Diese Replikationssysteme fragen meines Wissens aber nicht nach, welcher Eintrag der richtige ist und somit wird das mit der automatischen Synchronisation auch nix wirklich

Nochmal ganz deutlich: Eine logische Entscheidung über die Quelle eines Datensatz hat nichts, aber auch absolut gar nichts, mit der Entscheidung zu tun, welche Datensätze von welcher Session wann und wie lange und wieso und wo überhaupt gesperrt werden.

[mkinzler]

Kommt darauf an, wie deine Datenbankschema aussieht. haben die verschiedenen Bestände verschiedenen ID-Bereiche kann man schnell erkennne, welche Datensätze neu sind. Wird ein Änderungs-Timestamp geschrieben, kann man auch Änderungen an vorhandenen DS erkennen.

[Tim Henford]

Na schön, kein Grund gleich in die Luft zu gehen
Ich bin über jede Vereinfachung dankbar, nur wie soll ich sicherstellen, dass 2 User nicht kurz hintereinander unerwünschte Einträge machen.
Wie wird das dann im Netz verteilt und wie können diesen dann noch ausgewertet werden, sodass nicht plötzlich Einträge von einem anderen User gelöscht wurden, die ich aber nur änderen wollte?