Data Version Sistema nella tabella per una più facile sincronizzazione

I have a system that is on web, you can add data update it etc. Then you have a mobile phone which obtains the data from server.

Questo è abbastanza vago da coprire ogni tipo di comunicazione what-ever-ever.

In one word how will the device know when to sync?

Ci sono due modi. Il dispositivo può chiedere di sincronizzare e quindi ricevere dati. Funziona come un cliente. Il dispositivo può ricevere dati come notifica push. In questa seconda situazione il tuo dispositivo si comporta come un server.

La differenza essenziale è se il tuo dispositivo ha o meno il controllo di quando avviene questa comunicazione. Se non lo è, qualcos'altro è.

Also I thought of sending a version of every data to check if something is updated.

Questo è chiamato polling. Non è la situazione migliore per trovarti. Succede quando non sai quando succederà qualcosa, ma sei bloccato a comportarti come un cliente che è responsabile per decidere quando avverrà la comunicazione. Visto che non lo sai, continui a chiedere ripetutamente. Farlo ha serie prestazioni e conseguenze sulla larghezza di banda. È fastidioso come il quinquenne che canta "Ci siamo già?"

È molto meglio trovare un modo per permettere a qualcosa-che-sa-quando decidere di connettersi a te e dirti cosa è successo. Questi modi hanno molti nomi: eventi, notifiche push (notifica), aggiornamenti, post, chiamate e messaggi.

Se devi insegnare a qualcosa-che-sa-quando chi ha bisogno di dire che si chiama registrarsi come osservatore. Il modello di progettazione che insegna tutto questo è il schema di osservazione . La maggior parte degli esempi che troverai riguardano oggetti che comunicano tra thread. Indipendentemente dall'architettura in questione, seguire questo modello ti farà risparmiare dal polling.

Since I don't want to send each datas version, there could be 400 versions, and each one needs to be compared. I think that over time it would cause issues as the user base grows.

Tutto ciò che devi sapere è il cambiamento. Non hai bisogno dell'intera storia delle modifiche.

Estrarre questo cambiamento da un database è davvero il modo difficile per farlo. A meno che tu non stia tentando esplicitamente di eseguire la replica del database (un problema abbastanza difficile) è molto meglio avere tutto ciò che ha detto al database sulla modifica per informarti anche della modifica.

I database fanno code di messaggi abbastanza scadenti. Cercando di fargli fare questo genere di cose è essenzialmente cercando di costruire una coda di messaggi dopo il fatto. È come cercare di infrangere un uovo. È meglio trattare il database come un altro osservatore di qualcosa-che-sa-quando .

Ovviamente non sto dicendo che non puoi farlo nell'altro modo. Sto solo cercando di indicarti cosa potrebbe rendere questo un problema molto più facile.

Diciamo che abbiamo un unico numero di versione globale gestito dal server (in una tabella) e incrementa ogni transazione che è impegnata nel database.

E il database è configurato per mantenere anche una colonna del numero di versione in ogni tabella, in modo che ogni riga abbia un numero di versione. Ogni volta che una riga viene modificata o aggiunta, il numero di versione globale singolo per quella riga deve essere aggiornato al valore successivo per quel numero di versione globale singolo. (Una riga aggiornata avrà la sua colonna di versione aggiornata fino all'ultimo valore di versione in questione indipendentemente dal suo valore precedente.)

Inoltre, il server restituisce al client l'ultimo numero di quella singola versione generale su ciascuna query.

Quando si sincronizzano le informazioni sulla versione del client nella query, e quindi alle sue query dove clausole, per ciascuna tabella viene aggiunta una congiunzione che limita i risultati alle righe la cui versione delle modifiche è > = quel numero di versione.

Questo farà sì che il database faccia il lavoro di identificare le cose che sono cambiate dall'ultima versione (numero) data.

Il tuo chilometraggio varierà, poiché a volte i join ti vorrebbero la restrizione della versione e altre volte no (ad esempio una query a categorie di elementi, potresti volere articoli che cambiano, ma ottenere sempre tutte le loro categorie indipendentemente dalle modifiche nelle categorie ).

Quanto sopra fornisce un algoritmo per determinare esattamente cosa è cambiato dall'ultima sincronizzazione. Ora per quanto riguarda la domanda su quando sincronizzare. Come dice @CandidedOrange, il momento giusto per la sincronizzazione è quando si è verificato un cambiamento, poiché ora stiamo spingendo il cambiamento piuttosto che tirare / interrogare inutilmente.

Quindi, qualcuno, da qualche parte (il client o il server) deve capire l'ultima versione che ogni client ha effettivamente visto.

Come alluso a @CandidedOrange, il lavoro può essere suddiviso in due componenti:

(1) le notifiche del server cambiano, e spinge le notifiche. Se il server conosce il numero di versione più recente per ciascun client, può inviare le modifiche specifiche a ciascun client per i client che vedranno le modifiche (calcolandole secondo l'algoritmo precedente). Ma se il server non ha la versione più recente vista da ciascun client, quindi esegue il ping di tutto il client per provare un aggiornamento.

(2) Quando i client ricevono un ping, o ottengono il set di modifiche (se il server mantiene l'ultima versione del client) e nell'altro approccio il client si gira e tira le modifiche dal server con l'ultimo numero di versione del client, aggiornando come necessario.