Konzeptionelle Frage - Datenabgleich

[Rollo62]

Lustig wird das wenn ein Nummernkreis doch mal überläuft

[p80286]

Zitat von Rollo62:

Lustig wird das wenn ein Nummernkreis doch mal überläuft

Das wird schon vorher lustig, wenn Du zwei gültige Personen "Merkel, Angela" angelegt hast. Steht bei beiden als Beruf "Bundeskanzler" drin ist die Doppelbelegung klar. Aber was ist wenn zum einen "Bundeskanzler", zum anderen "Physiker" eingetragen ist? Dann unterschlagen wir in einem Datensatz den "Dr." und ich wünsche viel Erfolg bei der Verifikation.

Gruß
K-H

[jobo]

Sequenz/GUID/Überlauf:
Wir haben in einem Offline System für Bestellungen mal mit GUID gearbeitet. Hat problemlos funktioniert, allerdings sind in dem Kleinprojekt keine nennenswerten Mengen zustande gekommen.

Dubletten:
Diese Problematik ist ätzend, und am Ende ist der Physiker noch Sauer und eigentlich Chemiker!

Aber m.E. ist das Problem nicht unbedingt an verteilte Systeme bzw. technische ID gekoppelt. Also vlt. beide Probleme nicht in einer gemeinsamen Lösung vermischen.

[Edelfix]

Wir haben ein selbstgebautes Tool im Einsatz das mehrere ADS Datenbanken abgleichen soll. Es wird für jede Änderung ein Job angelegt. Der Job ist erst abgearbeitet wenn die Gegenstellen bestätigt dass die Änderung korrekt übertragen ist.

Das Ding macht immer wieder Probleme. Es ist teilweise Hell on Earth. Nummern Kreise laufen über. Oder gegenstelle hat ein neues Modem oder neu Software oder neue Hardware bekommen. Oder der Virenscanner meint alles zu blocken. Wir überwachen die Anzahl der Jobs um „Verstopfungen“ rechtzeitig zu erkennen. Am schlimmsten ist das die Gegenstelle nicht permanent erreichbar ist. Über eine Cloud Lösung wurde schon nachgedacht. Es sind aber über 30 Verbindungen die Synchronisiert werden. Naja kompliziertes Thema..

[himitsu]

So mancher nimmt hier als ID einen TIMESTAMP (mit Millisekunden) oder sowas wie eine GUID
und geht erstmal davon aus, dass es womöglich fast nie vorkommt, dass auf beiden Seiten genau zur selben Zeit ein Datensatz hinzukommt. (was natürlich aber dennoch einmal passieren könnte)



Da es aber dennoch ab und an mal vorgekommen ist, habe ich bei uns einige der Synchronisationen umgestellt.
Also intern wird mit einer Integer-ID gearbeitet, welche aber nur innerhalb einer DB genutzt wird, aber bei der Synchronisierung werden eine/mehrere andere eindeutige Spalten genutzt
und diese ID wird bei der Datenübertragung ignoriert.

Eventuell wird auch diese ID noch "umgerechnet", falls weitere Tabellen ebenfalls synchronisiert werden und sich über diese ID referenzieren.
Also in allen Tabellen/Daten diese ID von lokaler DB durch ID der anderen DB ersetzt, bei der Datenübertragung (referenziert über die Synchronisationsfelder).

[Neumann]

Mache folgendes:

Alle Tabellen, die gesendet oder empfangen werden, bekommen 3 zusätzliche Felder:
Lastchange Timstamp wird per Trigger gesetzt
Lastupdate Timestamp wird gesetzt wenn Datensatz exportiert wird, dann NOW + ein paar Sekunden
AGUID wird erzeugt wenn Datensatz erstmalig gesendet wird.

Der Empfänger prüft dann ob AGUID schon existiert, wenn ja dann Update sonst Insert.
Natürlich muss man noch auf Nummernkreise und ev. AutoInc-Felder achten.
Löschbefehle komme in Del-Tabellen, die auch automatisch angelegt werden.

Kommunikation geht entweder über eine einfache Soap-Schnittstelle oder über Dateien, die z.B. in einer Dropbox o. ä. geschrieben werden.
Bei Dateien liest der Empfänger die Daten ein und löscht sie dann.

Die Daten sind im JSON-Format.

Ich benutze eine sehr nützliche Funktion aus dem Delphi-MVC Framework, die sehr einfach den Export und Import von JSON-Arrays in Datasets ermöglicht.

Gibt natürlich noch einige Details, aber kann das jetzt nicht alles beschreiben

[himitsu]

Zitat von Neumann:

Lastchange Timstamp wird per Trigger gesetzt
Lastupdate Timestamp wird gesetzt wenn Datensatz exportiert wird, dann NOW + ein paar Sekunden

Hier kann man sich nun auch noch streiten.
Wir haben sowieso an fast allen Tabellen ein paar automatisch angelegte Felder für InsertTime, UpdateTime und wer das war.

Aber zusätzlich gibt es an synchronisierten Tabellen auch noch dieses "Modified"-Feld für die Synchro, wobei dieses Feld nicht nur angibt wer neuer ist, sondern auch für den Vergleich benutzt wird.
> Tja, nutzt man dieses Datumsfeld nun für einen billigen "hat sich was geändert"-Vergleich, oder vergleicht man da wirklich alle Spalteninhalte? (ausgenommen denen, welche von der Synchro ausgeschlossen sind)

[Hobbycoder]

In einer kleineren Testumgebung habe ich das vor relativ langer Zeit mal so gelöst:

Keine Replication auf DB-Ebene. Je eine DB an jedem Standort, und diese einmal vollständig übertragen.
Jede Tabelle hat ein Lock-Feld.

Wird nun ein Datensatz an Standort A zum Bearbeiten geöffnet, so wird sowohl der Datensatz sowohl in DB A als auch in DB B mittels dem Lock-Feld gesperrt. Heißt er kann nur noch zum Lesen geöffnet werden. Wird er nun in DB A gespeichert, dann wird dort das Lock direkt aufgehoben. Anschließen wird er dann in DB B gespeichert und erst danach das Lock auch dort aufgehoben.
Das ganze muss natürlich im Client passieren, oder man muss den DB-Zugriff über eine Server-Application regeln, die dann das Sperren und Entsperren passig übernimmt.
In die andere Richtung würde das genauso funktionieren. Und auch mit mehr als 2 Standorten.

Hat, wenn ich mich recht erinnere damals ohne Probleme funktioniert. War aber nur ein Test. Wir haben damals zwar einige an Traffic simuliert, aber ob es einem Echt-Betrieb standgehalten hätte kann ich nicht mit Sicherheit sagen. Sollte aber.

Das natürlich 2 User auf beiden Seiten zeitgleich den gleichen Kunden anlegen kann dieses Verfahren natürlich nicht verhindern. Und das Handling ist natürlich auch von der zur Verfügung stehenden Bandbreite abhängig.

Ob sich sowas auch auf DB-Ebene realisieren ließe, kann ich nicht sagen. Dazu fehlt mir das Wissen.

[p80286]

Zitat von jobo:

Dubletten:
Diese Problematik ist ätzend, und am Ende ist der Physiker noch Sauer und eigentlich Chemiker!

Hauptsache Naturwissenschaftler!

Zitat von jobo:

Aber m.E. ist das Problem nicht unbedingt an verteilte Systeme bzw. technische ID gekoppelt. Also vlt. beide Probleme nicht in einer gemeinsamen Lösung vermischen.

Da bin ich ganz anderer Meinung.
Du hast den Datenbankkunden, der Daten erfasst und diese natürlich sofort verfügbar haben will. (ich weiß, es gibt genügend Systeme, da sind neue/geänderte Daten erst am nächsten Arbeitstag verfügbar und an zwei Tagen im Jahr funktioniert es nicht richtig und schon ist das System S......)
Auf der anderen Seite der Admin/Programmierer, der eine funktionierende Formallösung sucht. Diese Formallösung zu finden, dafür wurden bisher schon genügend Ansätze skizziert. Aber sind damit auch die Ansprüche des Kunden abzudecken?
So lange alle Standorte weitgehend unterschiedliche Daten erfassen, - lesen ist ja kein Problem - bist Du mit einer rein formalen Lösung ganz gut bedient. Wenn es aber Datenüberschneidungen gibt, muß neben der formalen Programmlösung auch eine organisatorische Lösung her. Wie auch immer diese aussehen mag.

Nicht daß wir uns falsch verstehen, DDP-Systeme sind für 80%-Lösungen bei 50% der Kosten gut zu gebrauchen. Wer aber 100% will muß auch 100% zahlen.
(falls sich jemand fragt woher ich meine Prozente habe, meine ersten Schritte hab ich auf einer IB8100 gemacht)

Gruß
K-H

[jobo]

Zitat von p80286:

..
Da bin ich ganz anderer Meinung.
..

Nein, bist Du nicht. Natürlich muss eine praktikable Lösung für den Kunden rauskommen.
Ich wollte nur zum Ausdruck bringen, das es 2 verschiedene Probleme sind, die nicht unbedingt durch den gleichen, superschlauen Algorithmus zu lösen sind.