Come smettere di pensare & # 8220; relazionalmente & # 8221;

StackOverflow https://stackoverflow.com/questions/1043830

Domanda

Al lavoro, abbiamo recentemente avviato un progetto utilizzando CouchDB (un database orientato ai documenti). Ho avuto difficoltà a non apprendere tutte le mie conoscenze relazionali di database.

Mi chiedevo come alcuni di voi hanno superato questo ostacolo? Come hai smesso di pensare in modo relazionale e hai iniziato a pensare in modo documentale (mi scuso per aver inventato quella parola).

Qualche suggerimento? Suggerimenti utili?

Modifica : se fa la differenza, stiamo usando Ruby & amp; CouchPotato per connettersi al database.

Modifica 2 : SO mi dava fastidio di accettare una risposta. Ho scelto quello che mi ha aiutato a imparare di più, credo. Tuttavia, non esiste un vero "corretto" risposta, suppongo.

È stato utile?

Soluzione

Penso che, dopo aver esaminato un paio di pagine su questo argomento, tutto dipende dai tipi di dati con cui hai a che fare.

I RDBMS rappresentano un approccio top-down, in cui tu, il progettista del database, affermi la struttura di tutti i dati che esisteranno nel database. Definisci che una persona ha un nome, un cognome, un secondo nome e un indirizzo di casa, ecc. Se non hai una colonna per l'homehome di una persona, la sfortuna vuole essere una persona che ha un homePlanet diverso dalla terra; dovrai aggiungere una colonna in un secondo momento o i dati non potranno essere archiviati nel RDBMS. La maggior parte dei programmatori fa comunque ipotesi come queste nelle proprie app, quindi questa non è una cosa stupida da assumere e applicare. Definire le cose può essere buono. Ma se in futuro dovessi registrare altri attributi, dovrai aggiungerli. Il modello di relazione presuppone che i tuoi attributi di dati non cambieranno molto.

" Cloud " digita database usando qualcosa come MapReduce, nel tuo caso CouchDB, non fare il presupposto sopra, e guarda invece i dati dal basso verso l'alto. I dati vengono inseriti nei documenti, che potrebbero avere un numero qualsiasi di attributi variabili. Presuppone che i tuoi dati, per definizione, siano diversi nei tipi di attributi che potrebbero avere. Dice "So solo che ho questo documento nel database Persona che ha un attributo HomePlanet di" Eternium " e un nome di " Lord Nibbler " ma nessun cognome. " Questo modello si adatta alle pagine Web: tutte le pagine Web sono un documento, ma i contenuti / tag / chiavi effettivi del documento variano così ampiamente che non è possibile inserirli nella struttura rigida che il DBMS pontifica dall'alto. Questo è il motivo per cui Google pensa che il modello MapReduce roxors soxors, poiché il set di dati di Google è così vario che deve essere costruito per ambiguità fin dall'inizio, e grazie agli enormi set di dati è in grado di utilizzare l'elaborazione parallela (che MapReduce rende banale) . Il modello del database dei documenti presuppone che gli attributi dei tuoi dati possano / cambieranno molto o saranno molto diversi con "gap" e molte colonne scarsamente popolate che si potrebbero trovare se i dati fossero archiviati in un database relazionale. Mentre potresti usare un RDBMS per archiviare dati come questo, diventerebbe brutto molto velocemente.

Per rispondere alla tua domanda allora: non puoi pensare " relazionalmente " osservando un database che utilizza il paradigma MapReduce. Perché, in realtà non ha una relazione forzata. È una gobba concettuale che dovrai solo superare.

Un buon articolo che ho incontrato che confronta e contrappone abbastanza bene i due database è MapReduce: un grande passo indietro , che sostiene che i database di paradigma di MapReduce sono un passo indietro tecnologico e sono inferiori ai RDBMS. Non sono d'accordo con la tesi dell'autore e sostengo che il progettista del database dovrebbe semplicemente selezionare quello giusto per la sua situazione.

Altri suggerimenti

Riguarda i dati. Se si dispone di dati che hanno più senso a livello relazionale, un archivio documenti potrebbe non essere utile. Un tipico sistema basato su documenti è un server di ricerca, hai un enorme set di dati e vuoi trovare un articolo / documento specifico, il documento è statico o con versione.

In una situazione di tipo archivio, i documenti potrebbero letteralmente essere documenti, che non cambiano e hanno strutture molto flessibili. Non ha senso archiviare i loro metadati in un database relazionale, poiché sono tutti molto diversi, quindi pochissimi documenti possono condividere quei tag. I sistemi basati su documenti non memorizzano valori null.

I dati non relazionali / simili a documenti hanno senso quando vengono denormalizzati. Non cambia molto o non ti importa tanto della coerenza.

Se il tuo caso d'uso si adatta bene a un modello relazionale, probabilmente non vale la pena comprimerlo in un modello di documento.

Ecco un buon articolo su database non relazionali .

Un altro modo di pensarci è che un documento è una riga. Tutto in un documento è in quella riga ed è specifico per quel documento. Le righe sono facili da dividere, quindi il ridimensionamento è più semplice.

In CouchDB, come Lotus Notes, non dovresti davvero pensare a un documento come analogo a una riga.

Invece, un documento è una relazione (tabella).

Ogni documento ha un numero di righe - i valori dei campi: 

ValueID(PK)  Document ID(FK)   Field Name        Field Value
========================================================
92834756293  MyDocument        First Name        Richard
92834756294  MyDocument        States Lived In   TX
92834756295  MyDocument        States Lived In   KY

Ogni vista è una query a campi incrociati che seleziona tra tutti i documenti UNION ALL di ogni documento.

Quindi, è ancora relazionale, ma non nel senso più intuitivo, e non nel senso che conta di più: buone pratiche di gestione dei dati.

I database orientati ai documenti non rifiutano il concetto di relazioni, a volte permettono alle applicazioni di dereferenziare i collegamenti (CouchDB) o hanno persino un supporto diretto per le relazioni tra documenti (MongoDB). La cosa più importante è che i DODB sono senza schema. Negli archivi basati su tabelle questa proprietà può essere raggiunta con un notevole sovraccarico (vedi risposta di richardtallent), ma qui viene eseguita in modo più efficiente. Ciò che dovremmo davvero imparare quando si passa da un RDBMS a un DODB è dimenticare le tabelle e iniziare a pensare ai dati. Questo è ciò che pecsimulator chiama "bottom-up" approccio. È uno schema in continua evoluzione, non un letto procreano predefinito. Naturalmente questo non significa che gli schemi debbano essere completamente abbandonati in qualsiasi forma. La tua applicazione deve interpretare i dati, in qualche modo vincolarne la forma - questo può essere fatto organizzando documenti in raccolte, creando modelli con metodi di validazione - ma questo è ora il lavoro dell'applicazione.

potrebbe essere che dovresti leggere questo http://books.couchdb.org/relax/getting-started

Io stesso l'ho appena sentito ed è interessante ma non ho idea di come implementarlo nell'applicazione del mondo reale;)

Una cosa che puoi provare è ottenere una copia di Firefox e Firebug e giocare con le funzioni mappa e riduci in javascript. sono in realtà piuttosto interessanti e divertenti, e sembrano essere la base di come fare le cose in CouchDB

ecco il piccolo articolo di Joel sull'argomento: http: //www.joelonsoftware .com / articoli / 2006/08 / 01.html

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top