13

I've just started playing around with couchdb and I'm really liking it so far, but I was wondering when you should be creating a new database.

Here's what I mean:

If i were to create a blog on a server with multiple blogs and this was a RDBMS, I'd create a database called fox_blog and create tables and relations for the posts, comments, etc..

Now in CouchDB, I'd simply make 3 document types: posts, comments and user accounts.

But this is my question: Would I make one db called fox_blog and add a 'type' field to each of the documents (e.g., in the posts documents there would be a 'type' field with the value of 'post')? Or would I make a separate db for each document and precede the name with fox_ (e.g., db name would be fox_posts for the posts)? Or are neither of these correct?

Let me know if any of this is unclear, it was a bit hard to explain heh

Obto
  • 1,377
  • 1
  • 20
  • 33

3 Answers3

9

You should create a single database with a type field in each document.

You may want to write a view that returns the document and all its comments together.

Anand Chitipothu
  • 4,167
  • 4
  • 24
  • 26
7

Generally, I try to keep separate applications in each of their own database. In this case, if all the varying blogs are accessed within a single interface, keep it in 1 database, using fields like type and blog to identify each document.

If you are running multiple blogs, each accessed at their own domain or address, you may want to consider segmenting each of the blogs into their own database. Basically, CouchDB allows you a great deal of flexibility here, so take advantage of that and experiment.

Dominic Barnes
  • 28,083
  • 8
  • 65
  • 90
  • The only thing preventing me from doing this is how couch updates it's views every time there's an update. So take the comments for example. They are updated a lot more often than a blog entry would be, so wouldn't it be better to separate the comments from the posts in some cases (assuming I don't have a view that combines the posts and comments for some odd reason)? – Obto Jun 13 '11 at 16:54
  • 1
    Good discussion. Fox, you are right that there are more updates, however CouchDB will process (map/reduce) each document once each, basically after it is stored. Whether those are spread into multiple DBs or stored in just one, it will be roughly the same. I agree with Dominic, rule of thumb: keep it in one database when starting out. – JasonSmith Jun 14 '11 at 01:43
  • 1
    Alright I'm keeping all my fields in one db for now and it looks pretty good. But from my understanding now, if i find a certain document type is not being used in views that include the other documents, It could be a good idea to move it to its own db. Is that mindset correct? – Obto Jun 14 '11 at 18:46
5

More importantly doing queries across multiple DBs is not supported directly - although there are ways around this.

In your case with posts, comments and accts in separate DBs would not work at all.

You could use either duck-typing or using a type field "post/comment" etc.

CouchDB has a built-in user database that is accessible within your app too.

dch
  • 1,502
  • 9
  • 9