Normalizzazione Vs Join, trade-off

Question

Normalizzazione Vs Join, trade-off

#1 da (4 voti)

0

In RDBMS, obiettivi di normalizzazione:

Libera il database delle anomalie di modifica
Riduci a icona la riprogettazione quando estendi
Evita il pregiudizio verso un particolare modello di accesso

Il primo passo implica evitare la ridondanza ecc ...

Poiché i dati sono normalizzati e divisi in più tabelle, le operazioni di join sono necessarie per soddisfare le richieste poste dall'applicazione. l'operazione di join è costosa .

Con il modello relazionale, c'è un problema di disallineamento di un oggetto , cioè un divario tra mondo reale (accesso alle applicazioni) e mondo relazionale.

Sul contrasto, i database dei documenti (come MongoDB) non hanno problemi di disallineamento degli oggetti.

Il singolo fattore più importante nella progettazione dello schema del database con il database dei documenti riguarda, la corrispondenza dei modelli di accesso ai dati della tua applicazione. Quindi, la progettazione del database è piuttosto semplice.

Supportano anche transazioni , ora

Il problema di non normalizzazione viene comunque trasferito nel database Documento, a meno che non colleghi i dati tra raccolte e mappi / riduci sull'accesso alle applicazioni

Domanda:

Perché il database orientato ai documenti deve ancora sostituire il database del modello relazionale?

database mysql mongodb postgres normalization

posta user1787812 24.08.2017 - 20:23

fonte

1 risposta

Leggi altre domande sui tag database mysql mongodb postgres normalization

Trova sequenze sequenziali randomizzate per comprimere i file statisticamente Aggiornamento dell'oggetto valore nell'oggetto dominio. Assegna riferimento dall'esterno

score 4 · Answer 1

Bene, prima di tutto, la normalizzazione in un database relazionale non è un obiettivo assoluto. Ci sono certamente situazioni in cui il mantenimento di una tabella o colonna denormalizzata ha senso dal punto di vista delle prestazioni.

I database di documenti, per la maggior parte, non hanno affatto join. Invece, devi scrivere un codice che simuli un join, se ne hai bisogno. Il costo delle prestazioni di un join in un database relazionale è più che compensato dalla convenienza che fornisce, specialmente se i campi che partecipano al join sono correttamente indicizzati. Se hai bisogno di unirti comunque, potresti farlo anche in un sistema progettato specificamente per lavorare con i join.

I database relazionali traggono vantaggio da decenni di ricerca e perfezionamento e sono supportati da un corpus di conoscenze ben sviluppato da una solida comunità di utenti. Nonostante la mancata corrispondenza oggettuale relazionale, i database relazionali sono tuttavia adatti per le applicazioni aziendali, che comprendono almeno il 90 percento dello sviluppo del software attivo nell'industria.

I cosiddetti limiti di scalabilità dei database relazionali sono spesso esagerati; tali database possono avere dimensioni pari a terabyte e supportare miliardi di record. Hai solo bisogno di una soluzione big-data quando le tue dimensioni dei dati arrivano a centinaia di terabyte o petabyte. Un database relazionale può ancora gestire il lavoro il 95 percento delle volte.