Wie man aufhört "relational" zu denken

Question

Bei der Arbeit haben wir kürzlich ein Projekt mit CouchDB (einer dokumentenorientierten Datenbank) gestartet. Ich habe es schwer gehabt, mein gesamtes Beziehungswissen zu verlieren.

Ich frage mich, wie einige von euch dieses Hindernis überwunden haben? Wie hast du aufgehört, relational zu denken und beginne, dokumentarisch zu denken (ich entschuldige mich dafür, dieses Wort erfunden zu haben).

Irgendwelche Vorschläge? Nützliche Hinweise?

Bearbeiten: Wenn es einen Unterschied macht, verwenden wir Ruby & CouchPotato, um eine Verbindung zur Datenbank herzustellen.

Edit 2: SO hat mich geärgert, um eine Antwort zu akzeptieren. Ich habe diejenige ausgewählt, die mir am meisten geholfen hat, denke ich. Es gibt jedoch keine richtige "richtige" Antwort, nehme ich an.

Answer 1

Ich denke, nachdem Sie auf ein paar Seiten zu diesem Thema durchgelesen haben, hängt alles davon ab, mit welchen Arten von Daten Sie es zu tun haben.

RDBMSes stellen einen Top-Down-Ansatz dar, bei dem Sie, der Datenbankentwickler, die Struktur aller Daten in der Datenbank bestätigen. Sie definieren, dass eine Person einen ersten, letzten, zweiten Namen und eine Privatadresse usw. hat. Sie können dies mithilfe eines RDBMS erzwingen. Wenn du keine Spalte für den HomePlanet einer Person hast, eine Möchtegern-Person, die ein anderes HomePlanet als die Erde hat; Sie müssen zu einem späteren Zeitpunkt eine Spalte hinzufügen oder die Daten können nicht im RDBMS gespeichert werden. Die meisten Programmierer machen solche Annahmen in ihren Apps sowieso, also ist das keine dumme Sache, die man annehmen und durchsetzen kann. Dinge zu definieren kann gut sein. Wenn Sie jedoch in Zukunft weitere Attribute protokollieren müssen, müssen Sie sie hinzufügen. Das Beziehungsmodell geht davon aus, dass sich Ihre Datenattribute nicht wesentlich ändern.

"Cloud" -Datenbanken mit etwas wie MapReduce, in Ihrem Fall CouchDB, machen nicht die obige Annahme, und betrachten Sie stattdessen Daten von unten nach oben. Daten werden in Dokumenten eingegeben, die eine beliebige Anzahl unterschiedlicher Attribute aufweisen können. Es geht davon aus, dass Ihre Daten nach ihrer Definition unterschiedliche Arten von Attributen aufweisen. Es heißt: "Ich weiß nur, dass ich dieses Dokument in der Datenbank Person habe, das ein HomePlanet-Attribut von" Eternium "und einen Vornamen von" Lord Nibbler ", aber keinen Nachnamen hat." Dieses Modell passt Webseiten: Alle Webseiten sind ein Dokument, aber die tatsächlichen Inhalte/Tags/Schlüssel des Dokuments variieren so weit, dass Sie sie nicht in die starre Struktur einfügen können, von der das DBMS ausgeht. Aus diesem Grund hält Google das MapReduce-Modell für roxors soxors, weil die Datenmenge von Google so vielfältig ist, dass sie von Anfang an auf Mehrdeutigkeit ausgelegt werden muss und aufgrund der massiven Datenmengen die parallele Verarbeitung nutzen kann (MapReduce ist trivial). . Das Dokumentendatenbankmodell geht davon aus, dass sich die Attribute Ihrer Daten stark ändern oder "Lücken" aufweisen und viele dünn besetzte Spalten enthalten, die möglicherweise gefunden werden, wenn die Daten in einer relationalen Datenbank gespeichert sind. Während Sie ein RDBMS verwenden könnten, um solche Daten zu speichern, würde es sehr schnell hässlich werden.

Um Ihre Frage dann zu beantworten: Sie können nicht "relational" überhaupt denken, wenn Sie eine Datenbank betrachten, die das MapReduce-Paradigma verwendet. Weil es eigentlich keine erzwungene Beziehung hat. Es ist ein konzeptioneller Buckel, den du einfach überwinden musst.

---

Ein guter Artikel, den ich in das lief vergleicht und kontrastiert die beiden Datenbanken ziemlich gut MapReduce: A Major Step Back, die argumentiert, dass MapReduce Paradigma Datenbanken rückwärts ein technologischer Schritt, und sind zu RDBMSes minderwertig. Ich muss der These des Autors widersprechen und würde einwenden, dass der Datenbank-Designer einfach den für seine Situation richtigen auswählen müsste.

Answer 2

können Sie diese http://books.couchdb.org/relax/getting-started

lesen sollte ich mich gehört es einfach und es ist interessant, haben aber keine Ahnung, wie man realisiert, dass in der realen Welt Anwendung;)

Answer 3

Eine Sache, die Sie versuchen können, ist bekommen eine kopie von firefox und firebug, und spielen mit der karte und reduzieren funktioniert in javascript. sie sind eigentlich ganz cool und macht Spaß, und scheinen die Basis zu sein, wie die Dinge in CouchDB

hier zum Thema kleine Artikel Joel zu erledigen: http://www.joelonsoftware.com/items/2006/08/01.html

Answer 4

Es geht um die Daten. Wenn Sie Daten haben, die relational am sinnvollsten sind, ist ein Dokumentenspeicher möglicherweise nicht sinnvoll. Ein typisches dokumentenbasiertes System ist ein Suchserver, Sie haben einen riesigen Datensatz und möchten ein bestimmtes Dokument/Dokument finden, das Dokument ist statisch oder versioniert.

In einer Archivtyp-Situation könnten die Dokumente buchstäblich Dokumente sein, die sich nicht ändern und sehr flexible Strukturen haben. Es macht keinen Sinn, ihre Metadaten in relationalen Datenbanken zu speichern, da sie alle sehr unterschiedlich sind, sodass nur sehr wenige Dokumente diese Tags gemeinsam nutzen können. Dokumentbasierte Systeme speichern keine Nullwerte.

Nicht relationale/dokumentähnliche Daten sind sinnvoll, wenn sie denormalisiert werden. Es ändert sich nicht viel oder Sie interessieren sich nicht so sehr für Konsistenz.

Wenn Ihr Anwendungsfall gut zu einem relationalen Modell passt, lohnt es sich wahrscheinlich nicht, ihn in ein Dokumentmodell zu quetschen.

Hier ist ein guter Artikel über non relational databases.

Eine andere Denkweise ist, ein Dokument ist eine Zeile. Alles in einem Dokument befindet sich in dieser Zeile und ist spezifisch für dieses Dokument. Zeilen können einfach aufgeteilt werden, sodass die Skalierung einfacher ist.

Answer 5

In CouchDB, wie Lotus Notes, sollten Sie wirklich nicht über ein Dokument als analog zu einer Zeile denken.

Stattdessen ist ein Dokument eine Beziehung (Tabelle).

Jedes Dokument hat eine Anzahl von Zeilen - die Feldwerte:

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 

Jede Ansicht ist eine Quer Registerkarte Abfrage, die alles von jedem Dokument über eine massive UNION auswählt.

Also, es ist immer noch relational, aber nicht im intuitivsten Sinne, und nicht in dem Sinne, der am wichtigsten ist: gute Datenmanagement-Praktiken.

Answer 6

Dokument-orientierte Datenbanken lehnen das Konzept der Relationen nicht ab, sie lassen manchmal Anwendungen die Verknüpfungen der Dereferenzierung der Links (CouchDB) oder sogar direkte Unterstützung für Relationen zwischen Dokumenten (MongoDB). Was noch wichtiger ist, ist, dass DODBs schemalos sind. In Tabellen-basierten Speichern kann diese Eigenschaft mit erheblichem Overhead erreicht werden (siehe Antwort von richardtallent), aber hier ist es effizienter. Was wir wirklich lernen sollten, wenn wir von einem RDBMS zu einem DODB wechseln, ist, Tabellen zu vergessen und über Daten nachzudenken. Das nennt der Sheepsimulator den "Bottom-Up" -Ansatz.Es ist ein sich ständig weiterentwickelndes Schema, kein vordefiniertes Prokrustesbett. Das bedeutet natürlich nicht, dass Schemata in irgendeiner Form komplett aufgegeben werden sollten. Ihre Anwendung muss die Daten interpretieren, ihre Form irgendwie einschränken - dies kann durch Organisieren von Dokumenten in Sammlungen geschehen, indem Modelle mit Validierungsmethoden erstellt werden - aber das ist jetzt die Aufgabe der Anwendung.