migliori pratiche per la progettazione di database NoSQL


34

Ho appena iniziato a utilizzare un database basato su documenti NoSQL (MongoDB) e sono curioso di conoscere le migliori pratiche per la progettazione di database.

Presumo che l'architettura dovrebbe essere diversa dai database relazionali? Devo ancora puntare a un database normalizzato?

Ad esempio ho un caso d'uso particolare;

Ho un utente con una cronologia dei noleggi (array di indirizzi) che dovrebbe essere un array sull'utente o come una raccolta separata con una chiave condivisa?


Non usare chiavi esterne
dukeofgaming

Non usare SQL :-). Seriamente, "NoSQL" ti dice qualcos'altro sulla tecnologia?

Penso che questo thread dovrebbe essere nel sito del database di Stack Exchange. Lì puoi trovare ulteriore aiuto su questo problema.
Luis Arriojas,

Risposte:


23

Un approccio appropriato per la progettazione di database NoSQL è un DDD ( Domain Driven Design ). Per alcune persone che avevano l'abitudine di progettare RDBMS, NoSql sembra anti-pattern SQL e ha più senso se considerato nell'ambito di un DDD.

A seconda dell'utilizzo degli indirizzi, è possibile definirlo come oggetto valore all'interno del modello / entità della cronologia dei noleggi.

Ecco alcuni riferimenti che potrebbero chiarire le idee sulla progettazione con NoSQL:


19

TL; DR

La normalizzazione in RDBMS consente di sfruttare i punti di forza del paradigma relazionale.

La denormalizzazione in NoSQL consente di sfruttare i punti di forza del paradigma NoSQL.

Risposta lunga

Gli RDBMS sono fantastici perché ti consentono di modellare entità strutturate uniche (mutabili o meno) e le loro relazioni reciproche. Ciò significa che è molto facile lavorare a livello di entità, aggiornarne le proprietà, inserirne un altro, eliminarne uno, ecc. Ma è anche ottimo per aggregarli dinamicamente, un cane con il suo proprietario, un cane con le case in cui risiede, ecc. RDBMS offre strumenti per facilitare tutto ciò. Si unirà per te, gestirà i cambiamenti atomici tra le entità per te, ecc.

I database NoSQL sono fantastici perché consentono di modellare aggregati semi / non strutturati ed entità dinamiche. Ciò significa che è molto facile 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 anziché entità e relazioni. Quindi non hai persona, indirizzi di noleggio e una relazione tra di loro. Hai registri di noleggio che aggregano per ogni persona quali indirizzi di noleggio hanno avuto.

Devi chiedere, quali dati avrò 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 ingresso logico verso il resto dei dati.

NoSQL, diciamo, memorizza una cosa che ha altre cose che hanno cose proprie. Ridammi l'intera gerarchia delle cose. Permettetemi di cambiarlo come mi pare, ora sostituisco l'intera gerarchia delle cose con la mia cambiata. È praticamente tutto ciò che ti dà. Perché è utile Se quello che hai è una gerarchia di cose con cui interagisci sempre nel suo insieme. O se è necessario ridimensionare in modo massiccio.

Ogni altra cosa che RDBMS ti offre, dovrai implementarla manualmente nel codice e nel tuo schema. Dovrai unirti al codice se hai mai bisogno di un aggregato di aggregati. Dovrai analizzare se hai bisogno solo di una parte di un aggregato. Dovrai verificare 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. Poiché l'atomicità è garantita solo a quel livello, e anche le prestazioni. È importante capire presto le tue relazioni. Questo è ciò che è la denormalizzazione.

In RDBMS, la denormalizzazione rende efficace il tuo DB a un NoSQL. Quindi normalmente vuoi il contrario, cioè la normalizzazione. In caso contrario, dovresti invece utilizzare un DB NoSQL. A meno che tu non abbia bisogno di entrambi.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.