couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Barnes <>
Subject Re: Deciding on the structure of documents
Date Mon, 29 Mar 2010 00:20:53 GMT
Hi Ben, I don't have all the answers for you, but a few tips...

On posts and comments - It is important to think in terms of concurrency 
- a person will write and submit a post once, and people will reply in 
comments many times.

For the single-document situation: What if multiple people reply to the 
same post at the same time? The first comment to reach couchdb would 
succeed in updating the document, and the second comment would result in 
an error, because the doc revision is now out of date. A single-document 
situation would require the application logic to handle a revision 
error, and maybe automatically resubmit. This solution does not scale 
well - the more traffic and the more comments a site receives, the more 
likely these revision errors will occur.

For the each post/comment gets its own doc situation: There should be 
some checking in the application to make sure that people don't comment 
on non-existent posts, but unless space is at a premium this is perhaps 
not mandatory. (A cron job could delete any orphaned comments 
periodically, and without a related post comments would never been shown 
by a site)

On databases - The deciding factor about whether to use a single or 
multiple databases is often in backup/replication. If you need to be 
able to backup/replicate a shop's data separately to any other shop, 
then you'll probably be beset off with multiple databases.

If you have a common 'core' of products as you say and shops select a 
subset out of that, perhaps for maintainability it would be best to have 
only a single database? (For instance, so you don't have to modify the 
same product record over and over again, for each database)

Hope that helps,

On 28/03/2010 11:58 PM, Ben Hall wrote:
> Hello,
> I'm currently investigating the world of 'NoSQL' and CouchDB. I was
> wondering if anyone could point me in the direction of some good
> resources on how to decide on how to structure documents.  For
> example, I'm not sure on when you decide to store everything as a
> single document, or two separate documents (example - posts and
> comments).
> Also in terms of databases - how do you decide if you have one
> database, or multiple smaller databases with a subset of data ?
> Can relational rules about design still be applied?
> In terms of what I'm trying to achieve. I have a product category
> containing core ~100000 products. On top of this, each different
> 'shop' displays a subject of products.
> My initial idea was to have a separate database for each 'shop'
> containing the products they sell - but this results in a lot of
> duplication - how do you handle updates etc?
> Once you have the products, how do you handle categories of products etc...
> Any pointers on this would be great!
> Thank you
> Ben

View raw message