Database Reference
In-Depth Information
redis/populate_couch.js
redisClient.
multi(roleBatch).
exec(
function
(err, roles)
{
var
i=0,
artistDocs = [];
// Subdokumente für die Künstler aufbauen
artists.forEach(
function
(artistName) {
artistDocs.push({ name: artistName, role : roles[i++] });
});
// Neues Band-Dokument auf den Stapel schieben
bandsBatch.push({
_
id: couchKeyify( bandName ),
name: bandName,
artists: artistDocs
});
Mit der Befüllung der Band-Datenbank liegen nun alle von uns benötigten
Daten an einem einzigen Ort vor. Wir kennen die Namen vieler Bands, die
Künstler, die in diesen Bands gespielt haben und wir kennen deren Rollen
innerhalb der Bands.
Jetzt wäre ein guter Zeitpunkt, um eine kleine Pause zu machen, und mit un-
serem gerade befüllten Band-SOR in CouchDB unter
http://localhost:5984/
_
utils/database.html?bands
herumzuspielen.
Beziehungsspeicher
Als Nächstes steht unser Neo4j-Service auf dem Plan, mit der wir die Bezie-
hung zwischen den Künstlern und ihren Rollen nachhalten wollen. Natürlich
könnten wir CouchDB auch direkt über Views abfragen, doch bei komplexen,
auf Beziehungen basierenden, Queries sind wir recht beschränkt. Wenn Way-
ne Coyne von den Flaming Lips sein Theremin vor einem Konzert verliert,
könnten wir Charlie Clouser von Nine Inch Nails frage, der ebenfalls There-
min spielt. Oder wir könnten Künstler mit sich überschneidenden Talenten
aufspüren, selbst wenn sie in verschiedenen Bands unterschiedliche Rollen
übernehmen - all das mit einer einfachen Traversierung.
Nachdem unsere Ausgangsdaten nun an Ort und Stelle sind, müssen wir
Neo4j mit CouchDB synchron halten, sollten sich die Daten der Haupt-Da-
tenquelle jemals ändern. Darum schlagen wir zwei Fliegen mit einer Klap-
pe, indem wir einen Dienst entwickeln, der Neo4j mit allen Änderungen an
CouchDB seit Bestehen der Datenbank versorgt.
