Come gestire le modifiche nei dati duplicati in NoSQL

Question

Stiamo valutando NoSQL per un progetto imminente. Tendo a pensare a cose in un modo RDBMS e sto avendo problemi a concettualizzare la mancanza di normalizzazione.

Comprendo che i dati di duplicazione non sono considerati errati in NoSQL. Quello che ho difficoltà a capire è la correzione delle modifiche ai dati per prevenire anomalie.

Spiegazione dei Interrogazione Esempio:

si sta organizzando una serie di tornei di poker. Hai giocatori, località ed eventi del torneo. A quanto ho capito, un evento del torneo potrebbe contenere una posizione e una collezione di giocatori. È necessario che non abbia tutti i dati del giocatore, ma se si desidera ottenere i nomi e gli indirizzi di casa di tutti coloro che parteciperanno al prossimo torneo, tali informazioni devono essere incluse nella raccolta del torneo.

Qualcuno si è sposato e si è trasferito, cambiando il proprio cognome e l'indirizzo . L'applicazione deve aggiornare la collezione del giocatore e la raccolta del torneo? Oppure il mio modello delle collezioni è sbagliato? In che modo gli sviluppatori di "tengono traccia" di dove vengono duplicate le informazioni?

Answer 1

Il modello che vedo essere usato un po 'ultimamente è di avere un immutabile "master" raccolta di dati (nel tuo caso, la lista dei giocatori, l'elenco dei tornei con giocatori di ogni torneo modellato " relazionalmente ", dove il record del torneo ha una lista di id del giocatore), e una lista denormalizzata (nel tuo caso, una lista di tornei con i dati del giocatore completamente popolato) che viene sempre aggiornata eseguendo un processo periodico sul" master " "dati.

In questo modo l'applicazione deve solo aggiornare i dati anagrafici e il processo di aggiornamento periodico alla fine ricostruirà il risultato denormalizzato.

Answer 2

Una cosa da fare è avere un "sistema di registrazione" o master per ogni tipo di dati che si hanno. Non c'è bisogno di essere un'unica fonte per tutti i dati, ma ognuno dovrebbe averne uno.

Un'altra misura da prendere è rendere i dati versione (conservare i cambiamenti storici) in modo che i dati denormalizzati possano essere immutabili - nel tuo esempio i dati del giocatore per un torneo verificatosi in passato sono corretti per quel momento. Se un giocatore si è trasferito a un nuovo indirizzo da quel momento, è ancora possibile ottenerlo andando al "sistema di registrazione" del giocatore per ottenere l'indirizzo corrente ma il record del torneo riflette il suo indirizzo al momento ecc.