Sono nuovo con il concetto nosql, quindi quando inizio a imparare PouchDB, ho trovato questo grafico di conversione. La mia confusione è, come gestisce PouchDB se si dice di avere più tabelle, vuol dire che ho bisogno di creare più database? Perché dalla mia comprensione in pouchdb un database può archiviare molti documenti, ma un documento significa una riga in sql o sono frainteso?Struttura PouchDB
... cosa significa che ho bisogno di creare più database?
No.
... un documento significa una riga in SQL o sono io frainteso?
Proprio così. La tabella SQL definisce l'intestazione della colonna (nome e tipo) - che sono i nomi delle proprietà JSON del documento.
Quindi, tutti i documenti (righe) con le stesse proprietà (un cosiddetto "schema") sono l'equivalente della tabella SQL. Puoi avere tanti schemi diversi in un database come vuoi (visita json-schema.org per qualche ispirazione).
Come richiedere separatamente? Crea viste CouchDB! Puoi ottenere tutte/alcune "righe" dei tuoi dati tabulari (documenti con lo stesso schema) con una sola richiesta, come sai da SQL.
Per scrivere tali viste facilmente la proprietà type è molto comune per i documenti CouchDB. Il tuo nome conosciuto da una tabella SQL può essere il tuo tipo come doc.type: "animal"
I tuoi nomi di visualizzazione saranno probabilmente animalByName o animalByWeight. Dipende dalle tue esigenze
La risposta a questa domanda sembra essere sorprendentemente poco documentata. Mentre @llabball ha dato una risposta decente, non penso che le opinioni siano sempre la strada da percorrere.
Come si può leggere nella sezione herequando non usare la mappa/ridurre, Nolan spiega che per le applicazioni più semplici, la chiave è di abusi_ids, e sfruttare la potenza di allDocs().
In altre parole, se si dispone di due tipi distinti (ad esempio artisti e album), è possibile aggiungere un prefisso all'ID di ciascun tipo per ottenere un set di dati facilmente ricercabile. Ad esempio _id: 'artist_name' & _id: 'album_title', consentirebbe di recuperare facilmente gli artisti in ordine di nome.
Il layout dei dati in questo modo si tradurrà in prestazioni migliori a causa del non richiedere indici aggiuntivi e meno codice. Chiaramente, tuttavia, se i requisiti dei dati sono più complessi, le visualizzazioni sono la strada da seguire.
A volte il piano di più database è una buona opzione, come un database per utente o anche un database per utente. Dai uno sguardo allo this conversation sulla mailing list di CouchDB.