Perché dovrei usare un database basato su documenti come CouchDB invece di usare un database relazionale. Esistono tipi tipici di applicazioni o domini in cui il database basato su documenti è più adatto del database relazionale?
Risposte:
Probabilmente non dovresti :-)
La seconda risposta più ovvia è che dovresti usarlo se i tuoi dati non sono relazionali. Questo di solito si manifesta nel non avere un modo semplice per descrivere i tuoi dati come un insieme di colonne. Un buon esempio è un database in cui vengono effettivamente archiviati documenti cartacei, ad esempio tramite la scansione della posta dell'ufficio. I dati sono il PDF scansionato e hai alcuni metadati che esistono sempre (scansionati, scansionati da, tipo di documento) e molti possibili campi di metadati che esistono in qualche momento (numero cliente, numero fornitore, numero ordine, tieni un file fino a, Testo completo OCR, ecc.). Di solito non sai in anticipo quali campi di metadati aggiungerai nei prossimi due anni. Cose come CouchDB funzionano molto meglio per quel tipo di dati rispetto ai database relazionali.
Personalmente amo anche il fatto che non ho bisogno di librerie client per CouchDB tranne un client HTTP, che al giorno d'oggi è incluso in quasi tutti i linguaggi di programmazione.
La risposta probabilmente meno ovvia: se non senti alcun dolore usando un RDBMS, rimani con esso. Se devi sempre aggirare il tuo RDBMS per fare il tuo lavoro, un database orientato ai documenti potrebbe valere la pena dare un'occhiata.
Per un elenco più elaborato controlla questo post di Richard Jones .
CouchDB (dal loro sito Web )
Un server di database di documenti, accessibile tramite un'API JSON RESTful. Generalmente, i database relazionali non sono semplicemente accessibili tramite i servizi REST, ma richiedono un'API SQL molto più complessa. Spesso queste API (JDBC, ODBC, ecc.) Sono piuttosto complesse. REST è abbastanza semplice.
Ad-hoc e privo di schemi con uno spazio indirizzo piatto. I database relazionali hanno schemi complessi e fissi. Definisci tabelle, colonne, indici, sequenze, viste e altre cose. Couch non richiede questo livello di pianificazione avanzata complessa, costosa e fragile.
Distribuito, caratterizzato da una replica robusta e incrementale con rilevamento e gestione dei conflitti bidirezionali. Alcuni prodotti commerciali SQL offrono questo. A causa dell'API SQL e degli schemi fissi, questo è complesso, difficile e costoso. Per Couch, sembra semplice ed economico.
Interrogazione e indicizzazione, con un motore di report orientato alle tabelle che utilizza Javascript come linguaggio di interrogazione. Lo stesso vale per i database SQL e relazionali. Niente di nuovo qui.
Così. Perché CouchDB?
Per archiviare e servire stupidamente dati di altri server.
Nelle ultime due settimane ho giocato con un'app lifestream che esegue il polling dei miei feed (delizioso, flickr, github, twitter ...) e li memorizza in couchdb. Il bello di couchdb è che mi permette di mantenere i dati originali nella sua struttura originale senza spese generali. Ho aggiunto un campo 'class' a ciascun documento, memorizzando il server di origine e ho scritto una classe di rendering javascript per ogni sorgente.
Generalizzando, ogni volta che il tuo server comunica con un altro server è meglio una memoria senza schema poiché non hai alcun controllo sullo schema. Come bonus, couchdb utilizza i protocolli nativi di server e client: JSON per la rappresentazione e HTTP REST per il trasporto.
Mi viene in mente lo sviluppo rapido di applicazioni.
Quando evolvo costantemente il mio schema, sono costantemente frustrato dal dover mantenere lo schema in MySQL / SQLite. Anche se non ho ancora fatto troppo con CouchDB, mi piace quanto sia semplice evolvere lo schema durante il processo RAD.
Un caso in cui potresti non voler utilizzare un database non relazionale è quando hai molte relazioni molti-a-molti; Devo ancora capire come creare buone funzioni MapReduce attorno a questo tipo di relazioni, in particolare se è necessario disporre di metadati nella relazione di unione. Non ne sono sicuro, ma non credo che le funzioni di CouchDB Map possano chiamare le loro stesse query sul database, poiché ciò potrebbe potenzialmente causare cicli infiniti.
Utilizzare un database basato su documenti quando non è necessario archiviare dati in tabelle con campi di dimensioni uniformi per ciascun record. Invece, è necessario archiviare ciascun record come documento con determinate caratteristiche. Qualsiasi numero di campi di qualsiasi lunghezza può essere aggiunto dinamicamente a un documento in qualsiasi momento senza la necessità di "modificare la tabella" per prima. I campi basati su documenti possono contenere anche più parti di dati.
Elaborare su smdelfin: flessibilità. È possibile archiviare i dati in qualsiasi struttura (non strutturati e tutti) e ogni documento potrebbe essere completamente diverso. CouchDB è particolarmente utile perché con i loro indici di "visualizzazione", è possibile filtrare documenti specifici e interrogare solo quella vista quando si desidera quei sottoinsiemi del database.
Il mio più grande punto vincente di database di documenti che memorizzano i dati in formato JSON: questo è il formato nativo per JavaScript. Pertanto, le applicazioni Web JavaScript funzionano perfettamente con CouchDB. Di recente ho realizzato un'app Web che utilizza CouchDB ed è veloce come il razzo, ma anche in grado di gestire una struttura di dati in costante variazione.
I database basati su documenti hanno un grande vantaggio rispetto ai database relazionali in quanto non richiedono la definizione anticipata di uno schema prima di poter immettere dati.
Inoltre, è necessario utilizzare un database di documenti se i dati non sono relazionali e non possono essere archiviati in una tabella ma sono piuttosto un insieme di immagini o, ad esempio, articoli di giornale.
Un altro vantaggio è la facilità d'uso di database basati su documenti nello sviluppo web. Per un confronto più approfondito dei modelli di database NoSQL, controllare questa fonte: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf