Für eindeutige IDs würde ich eine
GUID nehmen. Ohne die geht es nicht.
Die Tabelle der durchgeführten Änderungen (eingefügt, gelöscht, verändert) als Basis für den Synchronisationsprozess ist schon richtig.
Wenn Du dann noch Konflikte behandelst (Änderungen widersprechen sich), bist Du fertig.
Ein Konflikt tritt z.B. dann auf, wenn der eine einen Datensatz löscht, ein Anderer den gleichen DS zwischenzeitlich jedoch verändert hat.
Oder beide verändern ein und das selbe Feld eines DS.
Du kannst hier entweder nach dem Prinzip "Last one wins" vorgehen, oder Du implementierst eine Konfliktbehandlung ("DS xy wurde von Schulze am BLABLA verändert, aber von Ihnen am BLABLUB gelöscht"). Da beim ersten Fall Datenänderungen unbemerkt verschwinden können, würde ich eine Konfliktbehandlung ("reconcile") implementieren. Das ist übrigens das sog. "briefcase model".
Um solche Konflikte sicher erkennen zu können, könntest Du dir merken, "wann" (und vom wem) ein Feld zum letzten Mal geändert wurde. Liegt dieser Zeitpunkt NACH deinem letzten Abgleich (und du hast diesen DS/Feld) verändert, liegt ein Konflikt vor.
Konfliktbehandlungen bekommst Du auch in den Griff, wenn Du dir eine Kopie der
DB ("Original") nach erfolgter Synchronisation erstellst und vor der nächsten Synchronisation die Daten mit dieser
DB-Version vergleichst: Hat sich ein zu ändernder Datensatz (Von 'A' nach 'B') zwischenzeitlich verändert, war die Änderung nicht exklusiv, es liegt dann also ein Konflikt vor. Du vergleichst also jeden DS VOR dem Abgleich mit dem Original. Damit erkennst Du zwar Konflikte, nicht jedoch, WER der Konfliktpartner ist.
Ich würde den ersten Weg wählen: Man hat auch eine sehr mächtige Änderungshistorie, was bei Geschäftsdaten nicht unerheblich ist. Du kannst dann auch Fragen beantworten, wie: "Wer hat denn damals den Ansprechpartner von Fa. Halmackenreuther geändert".