CODEWITHSUNDEEP
databasedatabase-designmapreducenosqlcouchdb
Tolga E
Tolga E

Reputation: 12678

If everything's denormalized, doesn't that make updates really slow (Author, blog example inside)

So I'm switching to NoSQL from SQL background. So I know I should be 'denormalizing' here.. So basically I have a simplified idea of what i have to do;

Users These documents hold authentication info, maybe payment method, username and all kinds of details

Posts These posts are made by users, and in each post, we have to display the username and email of a user. So by method of 'denormalizing', I would put the username and the email of the user into each post s/he makes.

But doesn't this create a problem when the user changes their username or email? Wouldn't I have to retroactively go and update all the posts?

Am I designing this correctly? Or missing something?

Upvotes: 1

Views: 133

Answers (1)

Aurélien Bénel
Aurélien Bénel

Reputation: 3842

In such cases, you're not obliged to denormalize data.

You can store users and posts as separate documents (in the same database):

{
  "_id":"alice",
  "email":"[email protected]"
}

{
  "author":"alice",
  "text":"Alice was beginning to get very tired of sitting by her sister on the bank, and of having nothing to do: once or twice she had peeped into the book her sister was reading, but it had no pictures or conversations in it, 'and what is the use of a book,' thought Alice 'without pictures or conversation?'"
}

Then you need a map function telling which field will be used for the join:

function(o) {
   if (o.text) {
     emit(o._id, {text:o.text, _id:o.author});
   }
}

Then call this view with include_docs=true and the ID of the post as the key.

Maybe it's an overkill to create an index just for this, but you can probably reuse it for something else useful (like "collating" blog posts and comments).

Upvotes: 2

Related Questions