FAQ

Komplexeres Dokument anlegen [S. 30]

Hier wird zwar gezeigt, wie komplexere Dokumente aussehen könnten, aber ich habe nirgends im Buch gesehen, wie man so ein komplexeres Dokument anlegen könnte.

Im folgenden Beispiel wird eine Datei 'daten.json' erstellt, in welche die zu speichernden JSON Daten geschrieben werden. Um die Validität der JSON Formatierung zu prüfen sei http://jsonlint.com/ empfohlen. Danach mit Hilfe des Programms curl ein POST Request an die lokale CouchDB complex ausgeführt und die Datei wird dem Request per '@' angehängt.

      $ export COUCH=http://localhost:5984
      $ vi daten.json
      {
        "artist": "Skeletor",
        "releases": [
          {
            "album_name": "First", 
            "year": 2001
          },
          {
            "album_name": "Last", 
            "year":2004
          }
        ]
      }
      $ curl -X POST $COUCH/complex/ -H "Content-Type: application/json" -d @daten.json
    

Bewusst Daten redundant speichern [S. 31]

"In einer dokumentbasierten Datenbank werden Daten ganz bewusst redundant gespeichert. Diese Tatsache bringt das Konzept mit sich."
Ich glaube, das stimmt so nicht. Wenn ich mich richtig erinnere, ist MongoDB auch dokumentenbasiert. Dort gibt es aber Referenzierungsmöglichkeiten. Darum muss man dort nichts redundant abspeichern.

Beziehungen zwischen den Daten sind in dokumentbasierten Datenbanken schwieriger zu modellieren. Ohne JOINs, usw. wird es einfach schwierig Daten zu aggregieren. Wenn viele Beziehungen notwendig sind, sollte man immer eher zu einem RDBMS greifen. Aus meiner Erfahrung heraus ist es prinzipiell nicht immer unmöglich aber z.B. sind dann mehrere Abfragen notwendig usw.. Daher auch die Empfehlung lieber Daten redunant zu speichern.

Unterschiedliche Ergebnisse von zwei unterschieldichen Instanzen in einem Cluster [S. 51]

"Wenn ich zum Beispiel dasselbe Dokument auf zwei CouchDB-Instanzen bearbeite, werden beim Lesen von den Instanzen jeweils unterschiedliche Ergebnisse geliefert ..."
Gibt es das Problem bei allen Artenvon Replikationen? Auch bei continuous Replication?

Ja, genau dafür gibt es die _rev im Dokument und conflict:true.

curl Optionen [S. S.57-58]

Dort werden die Optionen X, i, v und d erwähnt. Jedoch nicht die Option H.

Compaction [S. 74]

Dort wird erwähnt, dass man alte Dokument-Revisionen mit _compact eliminieren kann. Eliminiert das auch automatisch alte View-Revisionen?

Nein, es gibt drei unterschieldiche Arten Compaction anzuwenden.

Schreibweise "content-type" im Buch [S. 75]

'-H "content-type: ..." Soviel ich weiß, muss man content-type groß schreiben, also so: Content-Type

Laut RFC 2616 ist die durchgängige Schreibweise "Content-Type". Richtig. Allerdings muss ja der HTTP-Server an welchen der request gesendet werden mit der Schreibweise klar kommen. Der in CouchDB mitgelieferte HTTP Server tut dies. Allerdings werden wir in der zweiten Auflage des Buches die Schreibweise RFC 2616 konform ändern.

UUIDs [S. 77]

Hier wird erwähnt, dass UUIDs automatisch generiert werden. In MySQL gibt es auch ein "auto-increment". Ich vermute, in CouchDB gibt es nichts ähnliches. Ist das richtig?

Korrekt – UUID und auto_increment verfolgen auch zwei unterschiedliche Ziele. Das eine ist ein Counter, das andere ist ein tatsächlich einzigartige ID. Z.B. Du hast zwei MySQL-Server, auf jedem eine Tabelle "news". User A schreibt in Server1, User B in Server2. Auf einmal existieren zwei Einträge mit ID=2 – aber welcher gewinnt?

      CODE
    

Fehlende Anführungszeichen in Request [S. 78]

Beim ersten PUT-Befehl steht: " ... -d {} ...." Muss das {} nicht unter einfachen Anführungszeichen stehen?

Good catch ;-)! Aber ... nein. Wenn ein leerer JSON String übertragen wird, muss dieser nicht escaped werden. Allerdings wäre es guter Stil es an dieser Stelle auch zu tun.