Relazioni di documenti complessi nei database di documenti

3

Ho esaminato un certo numero di database di documenti (RavenDB, CouchDB, MongoDB) e ci sono due cose su di loro che mi piacciono molto e mi rende ciò che è necessario incorporarli il più possibile e che è lo schema meno naturale (non che siano schemi per-dire senza schema ma che sia uno schema molto flessibile che è molto più facile da modificare rispetto a quelli con RDBMS) e il fatto che ci sia molta meno corrispondenza di impedenza durante la mappatura dei dati del database al codice.

Ci sono state un certo numero di cose che ho trovato che mi hanno impedito di usare un database di documenti perché trovo che ho bisogno di queste cose tutto il tempo. Alcuni di loro ho trovato soluzioni per come campi unici. Mentre i database di documenti non supportano direttamente questa funzione, un lavoro attorno a ciò è accettabile è la creazione di un altro documento con l'e-mail è l'id del documento e quindi l'inserimento dell'utente se l'inserimento nel documento di posta elettronica è andato a buon fine, tuttavia c'è una cosa importante che non credo che il database dei documenti possa fornirmi dalla mia ricerca.

Questa caratteristica è la relazione con documenti complessi. Uno dei miei progetti che volevo utilizzare un database di documenti è un sistema di gestione dei progetti. Il problema con questo è che ci sono molti posti in cui ho bisogno di relazioni con oggetti di grandi dimensioni (e più relazioni all'interno di un documento). Quando si tratta di qualcosa di simile a un compito o un utente, questi sono documenti complessi e avere il documento incorporato non sarebbe una buona cosa dato che la mancata corrispondenza dei dati con questi elementi non può accadere. Ora, se faccio solo riferimento al documento, sto davvero beneficiando dell'uso di un database di documenti perché ora probabilmente avrò molte più query che devo eseguire rispetto a un database relazionale.

Mentre stavo saltando per avere la maggior parte dei miei dati memorizzati in un database di documenti, più lo guardo, sembra che la maggior parte dei dati debba essere in un RDBMS. Ho ragione nell'assumere che questo tipo di relazione abbia bisogno di un RDBMS o non sono consapevole di come ciò possa essere realizzato in un database di documenti.

    
posta ryanzec 22.03.2011 - 16:30
fonte

1 risposta

2

I database orientati ai documenti non sono progettati per rappresentare relazioni complesse tra i dati poiché i database relazionali lo fanno già bene. ;)

È possibile rappresentare relazioni complesse in doc-dbs ma influire negativamente sulle prestazioni - a causa della necessità di query multi-pass e multi-indice complesse - a meno che non si "denormalizzi" i dati che aumentano in modo significativo i requisiti delle risorse .

Un semplice esempio di ciò potrebbe essere la riorganizzazione del layout dei dati da:

{ 
   '_id':'abcd',
   'type':'user',
   'name':'rob'
}

{
   '_id':'zyxw',
   'type':'page',
   'user_id':'abcd'
}

che richiede due ricerche per trovare tutti i documenti appartenenti a "rob", a

{ 
   '_id':'abcd',
   'type':'user',
   'name':'rob'
}

{
   '_id':'zyxw',
   'type':'page',
   'owner': {
     'name':'rob'
   }
}

ne richiede solo uno.

Sì, questo va contro tutto ciò che ci è stato detto sulla progettazione dei dati, ma mentre i motori SQL sono ottimizzati per soddisfare query complesse rappresentando i dati in formato normale, doc-dbs è similmente ottimizzato per schemi senza dati a scapito della potenza espressiva della query (e della memoria).

    
risposta data 17.05.2011 - 23:07
fonte

Leggi altre domande sui tag