incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pete huerter <>
Subject CouchDB scenario - steering advise please
Date Wed, 08 Jan 2014 17:21:37 GMT
Hi All,

I am new here, and am writing to ask your advise on whether CouchDB is a
good fit for my needs. (*)  Thanks in advance for considering my case below.

I want to create a web-site where survivors of childhood abuse can come and
share with other survivors what has helped them recover and lead gainful
happy lives. (+)

In terms of scalability I am hoping a few hundred people would contribute,
possibly later into the thousands - simultaneously... hopefully that is.

This is all totally non-profit.  I have a technical background but in
compilers and debuggers to this area is pretty new to me.  If you are short
of time don't hold back I will pick through your response and figure it out.

The plan:

I am exploring the use of the CONCEPT MAP as the user interface.  By using
a concept map I hope to boil away most of the language issues and just get
to nouns (NODES) and pronouns, connectors, verbs (EDGES).  It needs to be
simple and easy to use.  I am not married to the concept map idea but I see
no other way of aggregating the experiences of many people in an intuitive
visualization that is easy for others to contribute to.

So imagine a DIRECTED GRAPH with nouns as nodes and pronouns,connectors,
verbs as edges.  I spent months wrestling with the semantics and I have
concluded that it should really stop thinking about it :)  The starter node
for everyone would be "I".  A node-edge-node would be "I"-"am
a"-"survivor". "survivor" could be refined to a particular form of abuse
(e.g. "i-am a-survivor-of-childhood xxxx abuse", and so on...  Each (new)
user would follow along in the graph adding his/her membership to each path
that is applicable to him her by clicking on that path (like breadcrumbs) -
but when that path no longer describes his/her personal experience they
could add their own sub graph to refine it to match their experience.  This
sub-graph would then be visible to all participants, who could in turn join
or refine as needed.  The system must remember what members belong to each
node and edge, also who pioneered that edge and likely other logging info.

So the graph mirrors consensus.  The goal is a graph that can be appended
and queried by many people at once.  The experience I am going for is "you
are not alone, and this is what has helped me in my particular case", and
"full recovery is possible".

My plan is to use D3.js to visualize the thing and I am wondering if a
CouchDB backend would work for me??  It needs to be simple otherwise I
probably will not get it done :)

Back to the idea of using a document store:

So I imagine a big document where nodes and edges are sub-documents.  Each
sub-document is itself a node/edge and records the membership and other
info in it.  So each sub-document would be updated with membership each
time a survivor clicks to "join" that node/sub-path, each document would
also be updated with new edges/nodes spanning from it.  A many-to-many
situation.  This is the data-intensive part.  The eventually consistent
aspect of CouchDB seems a good fit here as collisions will be common.

Later there may need to be features like editing node/edge data but not

Does CouchDB allow for many users to append to a document with reasonable
responsiveness?  Is there an append mode or something?

After filling 13 note books about how to make this fast and eliminate data
redundancy I am going back to what one of my profs said 15 years ago now:
"first make it work, then make it fast".  Actually the user interface may
be a complete flop so I need to work on that before worrying about

As I approach this project again after shelving it I am hopeful there are
some users who are understanding and knowledgeable who can take a min or
two to help steer me in any way they think may help.


(*)  A minute of your expert time would be greatly appreciated as in the
past I have learned that one email can often fend off weeks of unnecessary
work :)  Actually I have already gone around in circles for a few months so
this is me doing what I should have done months ago :)

(+) Of course this can be generalized, but I am using this domain as a
proof of concept.

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