Questa è la prima applicazione mongo-backed che sto cercando di fare al di là dei tutorial, quindi mi manca l'immaginazione quando si tratta di schemi di documenti.
Contesto :
In un'applicazione di datazione, esiste un algoritmo che identifica le corrispondenze tra gli utenti. Attualmente sto cercando di identificare come devono essere memorizzate queste corrispondenze.
Schema corrente :
Crea due documenti Match per coppia (uno per ogni utente), ognuno conterrà la risposta del suo utente, un riferimento all'altro utente e l'id del suo documento associato:
Match : {
objectid: [unique uuid],
user: [idx, uuid],
targetUser: [reference to User],
pair: [Match uuid],
approved: [bool / null]
}
Usecase :
Algorithm crea gli oggetti match. Viene effettuata una richiesta per recuperare tutte le potenziali corrispondenze User , interroghiamo il database per tutti gli oggetti Match per User , dove approvato è null . Il database popolerà il campo targetUser con il documento User effettivo [!!!] e restituirà. I risultati sono serializzati e inviati indietro.
...
L'utente approva la corrispondenza, la richiesta inviata all'aggiornamento Match[objectid].approved = True . Il back-end controlla il valore del secondo oggetto Match a cui fa riferimento pair e quindi attiva altre azioni a seconda del valore.
Preoccupazioni :
Prima di tutto, per qualcuno più esperto di NoSQL questo potrebbe sembrare orribile, nel qual caso per favore dimmelo. La mia preoccupazione principale è avere il riferimento a targetUser . Un grande punto di forza di NoSQL sta riducendo il numero di "join", ma non riesco a trovare un modo per evitarlo qui. Inoltre, il fatto di avere due oggetti per una coppia è un po 'preoccupante. Ma in quale altro modo direi: give me all potential matches for User A ?