database - motore - sql server documentazione




Perché dovrei usare un database basato su documenti invece del database relazionale? (4)

Perché dovrei usare un database basato su documenti come CouchDB invece di usare il database relazionale. Esistono tipi tipici di applicazioni o domini in cui il database basato su documenti è più adatto del database relazionale?


CouchDB (dal loro website )

  • Un server di database di documenti, accessibile tramite un'API JSON RESTful. Generalmente, i database relazionali non sono accessibili semplicemente 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 senza schemi con uno spazio di indirizzamento piatto. I database relazionali hanno uno schema complesso e fisso. Si definiscono tabelle, colonne, indici, sequenze, viste e altre cose. Il divano non richiede questo livello di pianificazione avanzata complessa, costosa e fragile.

  • Distribuito, con replica robusta e incrementale con rilevamento e gestione bidirezionale dei conflitti. Alcuni prodotti commerciali SQL offrono questo. A causa dell'API SQL e degli schemi fissi, questo è complesso, difficile e costoso. Per Couch, sembra semplice e poco costoso.

  • In grado di interrogare e di indicizzare, con un motore di report orientato alla tabella che utilizza Javascript come linguaggio di query. Così fanno i database SQL e relazionali. Niente di nuovo qui.

Così. Perché CouchDB?

  • REST è più semplice di JDBC o ODBC.
  • Nessuno schema è più semplice di Schema.
  • Distribuito in modo semplice e poco costoso.

Mi viene in mente lo sviluppo rapido di applicazioni.

Quando sono in continua evoluzione i miei schemi, sono costantemente frustrato dal dover mantenere lo schema in MySQL / SQLite. Anche se non ho ancora fatto molto 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 di MapReduce attorno a questi tipi di relazioni, in particolare se è necessario disporre di metadati nella relazione di adesione. Non sono sicuro, ma non credo che le funzioni di CouchDB Map possano chiamare le loro query sul database, poiché ciò potrebbe potenzialmente causare loop infiniti.


Probabilmente non dovresti :-)

La seconda risposta più ovvia è che dovresti usarla 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 si memorizzano effettivamente i documenti cartacei, ad esempio mediante la scansione della posta dell'ufficio. I dati sono i PDF scansionati e si hanno alcuni metadati che esistono sempre (scansionati, scansionati, tipo di documento) e molti possibili campi di metadati che esistono a volte (numero cliente, numero fornitore, numero ordine, file fino a quando, OCRed fulltext, ecc.). Di solito non sai in anticipo quali campi di metadati verranno aggiunti 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 alcuna libreria client per CouchDB eccetto un client HTTP, che è oggi incluso in quasi tutti i linguaggi di programmazione.

La risposta probabilmente meno ovvia: se non senti dolore usando un RDBMS, rimani con esso. Se devi sempre aggirare il tuo RDBMS per portare a termine il tuo lavoro, un database orientato ai documenti potrebbe valere la pena dare un'occhiata.

Per una lista più elaborata controlla questo post di Richard Jones .


Utilizzare un database basato su documenti quando non è necessario memorizzare i dati in tabelle con campi di dimensioni uniformi per ciascun record. Invece, è necessario memorizzare ogni record come documento che ha 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" prima. I campi in documenti possono anche contenere più porzioni di dati.





non-relational-database