NoSQL / Mongo: best practice per modellare le "relazioni" 1: 1?

Question

NoSQL / Mongo: best practice per modellare le "relazioni" 1: 1?

#1 da (1 voti)
#2 da (0 voti)

2

Vengo da molti anni a lavorare con SQL Server. Sto lavorando a un gioco per dispositivi mobili utilizzando GameSparks come back-end che supporta solo NoSQL su Mongo.

Sto creando un gioco di carte per computer e sto cercando di mettere alla prova le migliori pratiche per la creazione di documenti in raccolte che si riferiscono ad altri documenti di una collezione diversa.

Ad esempio, ho una collezione "giocatore" che contiene le informazioni sui giocatori: indirizzo email, nome utente, quel tipo di cose.

Ho una collezione separata chiamata "giocatoreCard". Questo contiene un documento per giocatore, simile alla collezione "giocatore". Il documento qui sarebbe link-in grado al giocatore dal playerID che è originario dalla collezione del giocatore.

Qual è la migliore pratica in questi casi in cui ho una relazione 1-1 per la creazione della chiave? La mia collezione di playerCards dovrebbe avere un "playerId" come indice per la propria collezione? OPPURE, le PlayerCards dovrebbero avere il proprio indice _id- > $ oid, che è unico per se stesso, e avere "playerId" solo essere un attributo sul documento?

Ho questo schema più e più volte nel mio design, con "playerDecks" (che rappresenta i mazzi creati dal giocatore), ecc.

Grazie per l'aiuto!

architecture nosql patterns-and-practices mongo

posta dferraro 15.10.2017 - 23:34

fonte

2 risposte

Leggi altre domande sui tag architecture nosql patterns-and-practices mongo

Progettazione di un modello di stato utente complesso Qualsiasi regola empirica quando scegliere il metodo di concatenamento [duplicato]

score 1 · Answer 1

Dipende principalmente dal modo in cui leggi o recuperi i dati dalle tue raccolte.

Dico perché non avere la carta giocatore all'interno del giocatore (annidata)? Ciò è dato dal fatto che recuperi solo la carta giocatore insieme al giocatore, e non c'è alcun caso di utilizzo per recuperare la carta giocatore da sola.

Se hai un caso d'uso per recuperare la carta del giocatore senza conoscere il giocatore, allora è meglio avere la carta giocatore e il giocatore che condividono la chiave (avere lo stesso valore per _id). Questo perché quando devi recuperare la carta giocatore per un giocatore, puoi usare l'ID documento (che è lo stesso dell'ID documento del giocatore). Questo invece di avere un attributo extra e un indice

score 0 · Answer 2

Di solito non è necessario inserire la mappatura in entrambe le raccolte perché puoi usare la ricerca per trovare una carta giocatore < - > mappatura del giocatore in qualsiasi documento. Supponiamo di averlo archiviato solo su playerCard, puoi cercare la PlayerCard usando playerId o playerCardId e dovresti riuscire a ottenere il documento.

Inserendolo in due punti, stai duplicando la mappatura, il che significa che quando cambierà, dovrai aggiornare entrambi i documenti. Se hai mai avuto una richiesta e l'altro ha esito negativo (nonostante i tentativi, ecc.), I tuoi dati saranno incoerenti. È meglio avere una fonte di verità.

Tuttavia, come parte della tua modellazione, potresti prendere in considerazione i tuoi casi d'uso futuri. In futuro introdurrai un concetto di gioco e un giocatore farà parte di più giochi? E vorresti mantenere una cronologia delle carte giocatore per giocatore, ecc.? Crea documenti in un modo che puoi facilmente espandere se i potenziali scenari futuri si insinuano.