Dati offline che dovranno essere importati in seguito

La logistica attuale non è troppo complicata (data dell'ultima modifica su ogni record e un timestamp "disconnected-since" o "last-synced" memorizzato da qualche parte), il vero problema sarà probabilmente il tuo conflitto tecnica di risoluzione. Cosa dovrebbe fare il sistema quando due persone modificano lo stesso campo nello stesso record?

Suggerirei di registrare tutte le modifiche offline apportate al database, quindi provare semplicemente a riprodurre o applicare tali modifiche alla successiva sincronizzazione dell'utente. Probabilmente è più efficiente del semplice controllo di ogni tabella per vedere se sono state apportate modifiche dall'ultima sincronizzazione. È anche possibile memorizzare sia i vecchi che i nuovi valori per tutti i campi che sono stati modificati. Ciò aiuterebbe con la risoluzione dei conflitti, dal momento che è ancora possibile aggiornare tutti i campi che contenevano ancora i loro vecchi valori, anche se la data dell'ultima modifica indicava che il record era stato modificato.

Le tue esigenze sono ideali per Microsoft Sync Framework . Tranne che per il bit di NHibernate, Sync Framework deve aggiungere alcune colonne ai dati per gestire la sincronizzazione e quelle in più "non giocano bene" con NHibernate. Un precedente datore di lavoro aveva un sistema di sincronizzazione sviluppato internamente, e ci sono molti casi limite di cui preoccuparsi, inclusi gli aggiornamenti che continuano ad andare avanti (l'elemento X dei dati viene aggiornato sul computer A, sincronizzato sul computer B, quindi è raccolto come una modifica e rimandato ad A, che poi lo rimanda a B, e così via). Se davvero devi creare il tuo sistema e ti sconsiglio vivamente, ti consiglio di dare un'occhiata a SyncML . Penso che il volume 4 di Pattern Languages of Program Design abbia un capitolo su un pattern di sincronizzazione.

Il cambiamento nella realtà è la finestra temporale associata all'aggiornamento dei dati. Se i dati possono essere aggiornati da più utenti oggi; la concorrenza, il blocco a livello di DB, ecc ... dovrebbero già essere presenti. Successivamente, l'ora in cui un utente conserva i dati prima di aggiornare il database è in qualche modo irrilevante.

A meno che tu non offra un'opzione di fusione, la sincronizzazione dovrebbe essere banale. Il database vince o l'utente vince, consente che tale scelta venga effettuata dall'utente.