Quindi ho, quella che sembrerebbe una domanda comune a cui non riesco a trovare risposta. Sto cercando di trovare qual è la "best practice" su come architettare un database che mantiene i dati localmente, quindi sincronizzare tali dati su un database remoto condiviso tra molti client . Per rendere le cose più chiare, questo database remoto avrebbe molti client che lo utilizzano.
Ad esempio, se avessi un'applicazione desktop che memorizza gli elenchi delle cose da fare (in SQL) con singoli elementi. Quindi voglio essere in grado di inviare quei dati a un servizio web che ha una copia "master" di tutte le informazioni sui diversi client. Non sono preoccupato di sincronizzare i problemi tanto quanto sto cercando di pensare attraverso l'architettura effettiva delle tabelle del client e delle tabelle dei servizi web
Ecco un esempio di come ci stavo pensando:
Database client
list
--list_client_id (primary key, auto-increment)
--list_name
list_item
--list_item_client_id (primary key, auto-increment)
--list_id
--list_item_text
Database principale basato sul Web (condiviso tra molti client)
list
--list_master_id
--list_client_id (primary key, auto-increment)
--list_name
--user_id
list_item
--list_item_master_id (primary key, auto-increment)
--list_item_remote_id
--list_id
--list_item_text
--user_id
L'idea sarebbe che il cliente possa creare elenchi di cose con gli oggetti e sincronizzarli con il servizio web in qualsiasi momento (cioè se perdono la connettività dei dati e non sono in grado di inviare le informazioni fino a più tardi, nulla uscire fuori ordine). Il servizio web registrerebbe i record con gli ID dei clienti come solo campi aggiuntivi. In questo modo, il client può dire "aggiorna la lista numero 4 con un nuovo nome" e il server prende questo per significare "aggiorna la lista numero 12 dell'utente 12 con un nuovo nome".