2010-11-21 4 views
1

Ich bin an die BigTable nosql db in Google AppEngine gewöhnt. Jetzt lerne ich CouchDB mit seinem Konzept von "Dokument". Ich bin nicht sicher, dass die zwei Dinge gleich sind. In der großen GAE-Tabelle modellieren Sie Ihre Daten genauso wie in einer relationalen Datenbank, abgesehen davon, dass es nur minimale Transaktionen gibt (nur zum Verknüpfen von Details mit einer Entität), keine Joins und keine Einschränkung für die Felder (jede Zeile kann unterschiedlich sein) Felder).Wie modelliere ich meine Domain für die Verwendung in couchDB?

Gilt das auch für couchDB? Gibt es andere Möglichkeiten, normale Entitäten abzubilden? Zum Beispiel für einen Bug Tracker, wie würden Sie Bug, User (wer hat den Bug geöffnet), Developer (wer soll das beheben), BugType und BugStatus?

+0

Sollte das nicht CouchDB sein? –

+0

ooops ... ja natürlich! – Uberto

Antwort

2

Es ist eine Weile her, seit ich GAE verwendet habe. Soweit ich mich erinnere, gibt es Modelle und alle Objekte des gleichen Modells haben die gleichen Attribute mit unterschiedlichen Werten. Sie können die Datenbank mit einer SQL-ähnlichen Abfragesprache abfragen.

In CouchDB alles, was Sie dort speichern, ist ein Dokument und Sie müssen Ihre Dokumente in kein Schema zwingen. Sie fragen Ihre Dokumente ab, indem Sie JavaScript-Funktionen schreiben, nicht indem Sie SQL schreiben und Tabellen verbinden. Stattdessen sollten Sie Ihre Daten so weit wie möglich denormalisieren.

Ich würde das folgende Beispiel-Dokument für einen Fehler vorschlagen:

{ 
    "_id" : "bug-1234", 
    "type" : "bug", 
    "state" : "new", 
    "user" : { 
     "name" : "user", 
     "email" : "[email protected]"}, 
    "developer" : { 
     "name" : "superdev", 
     "email" : "[email protected]", 
     "id" : "dev-123"}, 
    "title" : "this is the bug title", 
    "description" : "this is the bug description", 
    "comments" : [ 
     {"user" : "tom", "text" : "first!"}, 
     {"user" : "jerry", "text" : "LOL"} 
    ] 
} 

Dieser Blogpost Sie http://www.couch.io/migrating-to-couchdb

+0

danke.aber was ist mit Benutzer? Ich bin mir ziemlich sicher, dass ich ein anderes Dokument benötige, um Benutzer- und Entwicklerinformationen zu speichern, oder sollte ich sie für alle Fehler duplizieren? – Uberto

+0

Alle Beispiele, die ich bis jetzt gefunden habe, zeigen ein sehr triviales Datenmodell ohne Referenzen zwischen Entitäten. – Uberto

+0

Fügen Sie einfach die _id des Benutzers hinzu, wenn Sie zu einer Ansicht navigieren möchten, die benutzerzentriert ist. Avatare sollten als Anhänge zum Benutzerdokument gespeichert und dann wie folgt referenziert werden: db /: userid/avatar.jpg –

Verwandte Themen