Konzeptionelle Frage - Datenabgleich

[hoika]

Hallo,
ich hatte Integer benutzt.

[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..

[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.

[MyRealName]

Ohne jetzt den ganzen Strang zu lesen, meine Lösung für ein Mobiles Bestellwesen für Aussendienstler und ein autonomes POS ist folgendes :

Tabellen wie Produkte und Kunden kriegen ein Feld LU (LastUpdate, Datetime) und auf der Abgleichseite (also der mobilen app oder dem pos speicher ich mir für jede Tabelle (sind ja eh nicht viele) einfach nur wann ich dasletzte Mal nachgefragt habe.
Beim Sync sage ich dann nur

Tabelle: Produkte
LastUpdate: 13.02.2018 14:15:23.758 (also mit millisekunden eben)

und zurück kommen allen Zeilen aus der Tabelle, die einen LU timestamp haben, der neuer ist.

Das Ganze mache ich mit RealThinClient (RealThinClient.com), da kann ich ganze DataSets komprimiert übermitteln.
Auf der Clientseite geht das dann mit einem Batchmove (Append/Update) in meine lokale Tabelle.

Das nutze ich so seit 2 Jahren und alles ohne Probleme.

Hoffe, dass es hilft.

[p80286]

Zitat von 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.

OK in Zukunft halt ich mich raus Wenn Du geantwortet hast, wird eh ne Doublette draus!

Aber im Ernst, ich hab gerade Holgers Beitrag gelesen. Das "führende System" ist ein guter Ansatz. istzwar willkürlich aber erleichtert einiges.

Gruß
K-H

[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).