Questo requisito di dati si adatta a un database Document -Oriented?

0

Ho l'obbligo di consentire agli utenti di inserire voci di diario / diario al giorno. Voglio fornire una manciata di modelli di journal noti con colonne x da compilare. Un esempio potrebbe essere un diario del pensiero; un utente deve registrare un pensiero in una colonna, descrivere la situazione, valutare come si sono sentiti, ecc.

L'altro requisito è che un utente dovrebbe essere in grado di creare i propri modelli di diario. Potrebbero avere bisogno di un diario di 10 colonne al giorno e potrebbe essere necessario valutare un aspetto su 50 anziché su 10.

In un RDBMS, vedo che questo diventa piuttosto complicato. Potrei avere tabelle individuali per i miei modelli conosciuti poiché i campi verranno corretti. Ma per i modelli di diario personalizzati immagino che avrei bisogno di una tabella che memorizza custom_field_types (le colonne del diario), una tabella che memorizza le voci che fanno riferimento ai tipi di campo (custom_entries) e quindi una terza tabella custom_diary che memorizzerebbe le righe che corrispondono a custom_entries ai diari.

Lasciando da parte le prestazioni / il ridimensionamento, sarebbe più semplice o più sensato usare un database orientato ai documenti come MongoDB per archiviare questi dati?

Questo è per un'applicazione web che potrebbe in seguito necessitare di un'API per dispositivi mobili.

    
posta codecowboy 20.08.2012 - 17:54
fonte

1 risposta

2

Penso che il fatto che tu stia chiedendo un database di documenti è probabilmente una ragione sufficiente per usarlo. Generalmente l'aspetto più importante da considerare in scelte come questa è se la squadra ha abilità / esperienza con una tecnologia. Se sei aperto a provare un database di documenti, potrebbe essere sufficiente.

Ma, da un aspetto più tecnologico, i database di documenti generalmente significano cose come nessun join a livello di database, nessuna transazione, nessuna garanzia ACID. Dico "generalmente" perché ogni database di documenti è diverso. Quel genere di cose deve essere implementato a livello di applicazione. Se generalmente non si hanno aggiornamenti simultanei ai dati (o nessun aggiornamento, ad esempio una volta che un documento viene scritto, viene letto solo) i database dei documenti sono ottimali perché potrebbero non essere necessarie transazioni.

Se stai guardando dati strutturati ma non specifici, RDBMS, come dici tu, potrebbe essere molto impegnativo. Se ogni utente ha il potenziale per archiviare ciò che effettivamente diventa un dato strutturato su misura, un database di documenti sembra una scelta migliore. Ma dipende. Un archivio di chiavi / valori potrebbe funzionare anche molto bene in una situazione come questa.

Se stai guardando cose come ETL o rapporti, allora RDBMS 'a volte può essere una scelta migliore. Hanno una migliore selezione di strumenti per supportare cose come questa. Qualsiasi necessità di replica potrebbe anche influenzare la scelta di RDBMS o meno. Alcuni database di documenti supportano la replica e molti elementi di supporto.

se stai guardando la distribuzione dei dati, nosql in generale è spesso una scelta migliore. RDBMS può essere fatto funzionare in situazioni come questa ma può finire con alcuni problemi di prestazioni. Questo di solito non è un problema finché non si raggiungono carichi molto elevati su dati molto grandi.

Considerato lo stato attuale dei database di documenti, non riesco a pensare a molte situazioni in cui non si adattano realmente solo dal punto di vista dello storage dei dati. Esistono situazioni di grandi quantità di dati molto cariche in cui alcune implementazioni potrebbero introdurre alcuni problemi di prestazioni. Ma questo è davvero raro e spesso termina con la creazione di un nuovo database nosql progettato specificamente per lo scenario di quella organizzazione.

Suggerirei di implementare una dimostrazione del concetto rapida e sporca per avere un'idea del lavoro svolto. Se ritieni che la sua drasticità sia inferiore a quella di un RDBMS, questo potrebbe essere il fattore decisivo, a meno che non sia un requisito specifico di SQL come i rapporti di terze parti (come la BI).

    
risposta data 21.08.2012 - 05:55
fonte

Leggi altre domande sui tag