représentant une relation plusieurs-à-plusieurs dans couchDB

Question

Supposons que j'écris une application d'analyse de journal. L'objet de domaine principal serait un LogEntry. En outre. Les utilisateurs de l'application définissent un LogTopic décrivant les entrées de journal qui les intéressent. Lorsque l'application reçoit des entrées de journal, elle les ajoute à couchDB et les compare également à tous les LogTopics du système pour voir si elles correspondent aux critères de la rubrique. . Si tel est le cas, le système doit enregistrer que l'entrée correspond au sujet. Ainsi, il existe une relation plusieurs à plusieurs entre LogEntries et LogTopics.

Si je stockais cela dans un SGBDR, je ferais quelque chose comme:

CREATE TABLE Entry (
 id int,
 ...
)

CREATE TABLE Topic (
 id int,
 ...
)

CREATE TABLE TopicEntryMap (
 entry_id int,
 topic_id int
)

Utilisation de CouchDB J'ai d'abord essayé de ne disposer que de deux types de documents. J'aurais un type LogEntry, ressemblant à ceci:

{
  'type': 'LogEntry',
  'severity': 'DEBUG',
  ...
}

et j'aurais un type LogTopic, ressemblant à ceci:

{
  'type': 'LogTopic',
  'matching_entries': ['log_entry_1','log_entry_12','log_entry_34',....],
  ...
}

Vous pouvez constater que je représente la relation en utilisant un champ matching_entries dans chaque document LogTopic pour stocker une liste d'identifiants de document LogEntry. Cela fonctionne bien jusqu'à un certain point, mais j'ai des problèmes lorsque plusieurs clients tentent tous deux d'ajouter une entrée correspondante à un sujet. Les deux tentent des mises à jour optimistes et une échoue. La solution que j'utilise maintenant consiste essentiellement à reproduire l'approche du SGBDR et à ajouter un troisième type de document, du type:

{
  'type':'LogTopicToLogEntryMap',
  'topic_id':'topic_12',
  'entry_id':'entry_15'
}

Cela fonctionne et élimine les problèmes de mise à jour simultanés, mais j'ai deux réserves:

1. Je crains que je ne me sers que de cela approche parce que c'est ce que je ferais dans une base de données relationnelle. Je me demande s'il y a un peu plus comme CouchDB (relaxant?) Solution.
2. Mes vues ne peuvent plus récupérer toutes les entrées pour un sujet spécifique dans un appel. ma solution précédente permettait cela (si je utilisé le paramètre include_docs).

Quelqu'un a-t-il une meilleure solution pour moi? Cela aiderait-il si je publiais également les vues que j'utilise?

Answer 1

Votre approche est correcte. Utiliser CouchDB ne signifie pas que vous abandonnerez simplement la modélisation relationnelle. Vous aurez besoin d’exécuter deux requêtes mais c’est parce que c’est une & "Rejoindre &"; Les requêtes SQL avec jointures sont également lentes, mais la syntaxe SQL vous permet d’exprimer la requête en une seule instruction.

Au cours de mes quelques mois d’expérience avec CouchDB, c’est ce que j’ai découvert:

1. Pas de schéma, la conception des modèles d'application est donc rapide et flexible
2. CRUD est là pour développer votre application rapidement et avec souplesse
3. Au revoir injection SQL
4. Ce qui serait une jointure SQL nécessite un peu plus de travail dans CouchDB

En fonction de vos besoins, j'ai découvert que couchdb-lucene était également utile pour la création de requêtes plus complexes.

Answer 2

J'ai posté cette question à la liste de diffusion des utilisateurs de couchdb et à Nathan Stott < un href = "http://markmail.org/message/vsvwyz4rccc33jox" rel = "noreferrer"> m'a indiqué un article de blog très utile de Christopher Lenz

Answer 3

J'essaierais de configurer la relation pour que LogEntrys sache à quel LogTopics ils appartiennent. De cette façon, l'insertion d'un LogEntry ne produira pas de conflits, car les LogTopics n'auront pas besoin d'être modifiés.

Ensuite, une fonction de carte simple émettrait le LogEntry une fois pour chaque LogTopic auquel elle appartient, créant essentiellement votre TopicEntryMap à la volée:

"map": function (doc) {
    doc.topics.map(function (topic) {
        emit(topic, doc);
    });
}

De cette manière, interroger la vue avec un argument ?key=<topic> vous donnera toutes les entrées appartenant à un sujet.