couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Stott <nrst...@gmail.com>
Subject Re: representing many-to-many relations with concurrent inserts
Date Mon, 30 Nov 2009 22:09:11 GMT
You may find this blog post helpful:
http://www.cmlenz.net/archives/2007/10/couchdb-joins

On Mon, Nov 30, 2009 at 3:21 PM, Pete Hodgson <public@thepete.net> wrote:

> Hi list,
>
> I'm a newbie with couchDB, so please forgive any transgressions. Also, I'm
> cross-posting this question to Stack Overflow,
>
> http://stackoverflow.com/questions/1822444/representing-a-many-to-many-relationship-in-couchdbI
> hope that's not considered rude.
>
> Let's say I'm writing a log analysis application. The main domain object
> would be a LogEntry. In addition. users of the application define a
> LogTopic
> which describes what log entries they are interested in. As the application
> receives log entries it adds them to couchDB, and also checks them against
> all the LogTopics in the system to see if they match the criteria in the
> topic. If it does then the system should record that the entry matches the
> topic. Thus, there is a many-to-many relationship between LogEntries and
> LogTopics.
>
> If I were storing this in a RDBMS I would do something like:
>
> CREATE TABLE Entry (
>  id int,
>
>  ...
> )
>
> CREATE TABLE Topic (
>
>  id int,
>  ...
> )
>
> CREATE TABLE TopicEntryMap (
>
>  entry_id int,
>  topic_id int
> )
>
> Using CouchDB I first tried having just two document types. I'd have a
> LogEntry type, looking something like this:
>
> {
>  'type': 'LogEntry',
>
>  'severity': 'DEBUG',
>  ...
> }
>
> and I'd have a LogTopic type, looking something like this:
>
> {
>  'type': 'LogTopic',
>
>  'matching_entries': ['log_entry_1','log_entry_12','log_entry_34',....],
>
>  ...
> }
>
> You can see that I represent the relationship by using a
> matching_entriesfield in each LogTopic documents to store a list of
> LogEntry document ids.
> This works fine up to a point, but I have issues when multiple clients are
> both attempting to add a matching entry to a topic. Both attempt optimistic
> updates, and one fails. The solution I'm using now is to essentially
> reproduce the RDBMS approach, and add a third document type, something
> like:
>
> {
>  'type':'LogTopicToLogEntryMap',
>
>  'topic_id':'topic_12',
>  'entry_id':'entry_15'
> }
>
> This works, and gets past the concurrent update issues, but I have two
> reservations:
>
>   1. I worry that I'm just using this approach because it's what I'd do in
>   a relational DB. I wonder if there's a more couchDB-like (relaxful?)
>   solution.
>   2. My views can no longer retrieve all the entries for a specific topic
>   in one call. My previous solution allowed that (if I used the
> include_docs
>   parameter).
>
> Anyone have a better solution for me? Would it help if I also posted the
> views I'm using?
> Cheers,
> Pete
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message