Ho appena iniziato a utilizzare un database basato su documenti NoSQL (MongoDB) e sono curioso delle migliori pratiche per la progettazione di database.
Suppongo che l'architettura dovrebbe essere diversa dai database relazionali? Dovrei comunque mirare a un database normalizzato?
Ad esempio, ho un caso d'uso particolare;
I have a user with a rental history (array of addresses) should that array be an array on the user or as a separate collection with a shared key?
Un approccio appropriato per la progettazione del database NoSQL è un DDD ( Domain Driven Design ). Per alcune persone che progettavano RDBMS, NoSql ha l'aspetto di anti-pattern Sql e ha più senso se considerato nell'ambito di un DDD.
A seconda dell'utilizzo degli indirizzi, è possibile definirlo come un oggetto valore all'interno del modello / entità della cronologia delle locazioni.
Ecco alcuni riferimenti che potrebbero chiarire i pensieri sul design con NoSQL:
La normalizzazione in RDBMS ti consente di sfruttare i punti di forza del paradigma relazionale.
La denormalizzazione in NoSQL ti consente di sfruttare i punti di forza del paradigma NoSQL.
Gli RDBMS sono grandi perché consentono di modellare entità strutturate uniche (mutabili o meno) e le loro relazioni reciproche. Ciò significa che è molto semplice lavorare a livello di entità, aggiornarne le proprietà, inserirne un'altra, cancellarne una, ecc. Ma è anche ottima per aggregarle dinamicamente, un cane con il suo proprietario, un cane con le case in cui risiede, ecc. Il RDBMS ti offre strumenti per facilitare tutto questo. Si unirà per te, gestirà le modifiche atomiche tra le entità per te, ecc.
I database NoSQL sono grandi perché consentono di modellare gli aggregati semi / non strutturati e le entità dinamiche. Ciò significa che è molto semplice modellare entità in continua evoluzione, entità che non condividono tutti gli stessi attributi e aggregati gerarchici.
Per modellare NoSql, è necessario pensare in termini di gerarchia e aggregati invece di entità e relazioni. Quindi non hai persone, indirizzi di noleggio e una relazione tra loro. Hai dei record di noleggio che aggregano per ciascuna persona quali indirizzi di noleggio hanno avuto.
Devi chiedere, quali dati ho bisogno di cambiare insieme. Quali dati raggruppano logicamente gli altri dati. Nel tuo caso una persona suona come un buon aggregato. Qual è il punto di accesso logico verso il resto dei dati.
NoSQL diciamo, immagazzina qualcosa che ha altre cose che hanno le cose da sole. Dammi tutta la gerarchia delle cose. Consentitemi di cambiarlo a mio piacimento, ora sostituisco l'intera gerarchia di cose con la mia persona cambiata. Questo è praticamente tutto ciò che ti dà. Perché è utile? Se quello che hai è una gerarchia di cose con cui interagisci sempre nel suo complesso. O se hai bisogno di scalare in modo massiccio.
Ogni altra cosa ti dà RDBMS, dovrai implementare manualmente nel codice e nel tuo schema. Dovrai unirti al codice se hai bisogno di un aggregato di aggregati. Dovrai analizzare se hai bisogno solo di una parte di un aggregato. Dovrai controllare tu stesso l'unicità se non vuoi cose duplicate. Dovrai implementare la tua logica transazionale quando lavori su aggregati, ecc.
Quindi avere un grande tavolo con tutto ciò di cui hai bisogno è la strada da percorrere in NoSql. Dal momento che l'atomicità è garantita solo a quel livello e anche le prestazioni. Capire presto i tuoi rapporti è importante. Questo è ciò che la denormalizzazione è.
In RDBMS, la denormalizzazione blocca efficacemente il tuo DB in uno NoSQL. Quindi normalmente vuoi il contrario, cioè la normalizzazione. Se non lo fai, dovresti usare invece un DB NoSQL. A meno che non ti serva un po 'di entrambi.