che rappresenta una relazione molti-a-molti in couchDB

Question

Diciamo che sto scrivendo un'applicazione per l'analisi dei log. L'oggetto dominio principale sarebbe un LogEntry. Inoltre. gli utenti dell'applicazione definiscono un LogTopic che descrive a quali voci di registro sono interessati. Quando l'applicazione riceve voci di registro, le aggiunge a couchDB e le verifica anche con tutte le LogTopics nel sistema per vedere se corrispondono ai criteri nell'argomento . In tal caso, il sistema dovrebbe registrare che la voce corrisponde all'argomento. Pertanto, esiste una relazione molti-a-molti tra LogEntries e LogTopics.

Se lo memorizzassi in un RDBMS farei qualcosa del tipo:

CREATE TABLE Entry (
 id int,
 ...
)

CREATE TABLE Topic (
 id int,
 ...
)

CREATE TABLE TopicEntryMap (
 entry_id int,
 topic_id int
)

Usando CouchDB ho prima provato ad avere solo due tipi di documenti. Avrei un tipo LogEntry, simile a questo:

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

e avrei un tipo LogTopic, simile a questo:

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

Puoi vedere che rappresento la relazione utilizzando un campo matching_entries in ciascun documento LogTopic per memorizzare un elenco di ID documento LogEntry. Funziona bene fino a un certo punto, ma ho problemi quando più client stanno entrambi tentando di aggiungere una voce corrispondente a un argomento. Entrambi tentano aggiornamenti ottimistici e uno fallisce. La soluzione che sto usando ora è essenzialmente riprodurre l'approccio RDBMS e aggiungere un terzo tipo di documento, qualcosa del tipo:

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

Funziona e supera i problemi di aggiornamento simultanei, ma ho due riserve:

1. Temo che sto solo usando questo approccio perché è quello che farei un DB relazionale. Mi chiedo se ci sia un più simile a couchDB (rilassante?) soluzione.
2. Le mie visualizzazioni non possono più recuperare tutte le voci per a argomento specifico in una chiamata. Mio soluzione precedente ha permesso che (se io utilizzato il parametro include_docs).

Qualcuno ha una soluzione migliore per me? Sarebbe di aiuto se avessi pubblicato anche le visualizzazioni che sto usando?

Answer 1

Il tuo approccio va bene. L'uso di CouchDB non significa che abbandonerai solo la modellazione relazionale. Sarà necessario eseguire due query ma questo è perché si tratta di un & Quot; join & Quot ;. Anche le query SQL con join sono lente ma la sintassi SQL consente di esprimere la query in un'istruzione.

Nei miei pochi mesi di esperienza con CouchDB questo è quello che ho scoperto:

1. Nessuno schema, quindi la progettazione dei modelli di applicazione è veloce e flessibile
2. CRUD è lì, quindi lo sviluppo della tua applicazione è veloce e flessibile
3. Arrivederci SQL injection
4. Quello che sarebbe un join SQL richiede un po 'più di lavoro in CouchDB

A seconda delle tue esigenze ho scoperto che couchdb-lucene è utile anche per creare query più complesse.

Answer 2

Ho inviato questa domanda alla mailing list degli utenti couchdb e Nathan Stott < a href = "http://markmail.org/message/vsvwyz4rccc33jox" rel = "noreferrer"> mi ha indicato a post di blog molto utile di Christopher Lenz

Answer 3

Proverei a impostare la relazione in modo che LogEntrys sappia a quale LogTopics appartengono. In questo modo, l'inserimento di un LogEntry non produrrà conflitti poiché LogTopics non dovrà essere modificato.

Quindi, una semplice funzione di mappa emetterebbe LogEntry una volta per ogni LogTopic a cui appartiene, essenzialmente costruendo al volo la tua TopicEntryMap:

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

In questo modo, l'interrogazione della vista con un ?key=<topic> argomento ti darà tutte le voci che appartengono a un argomento.