CODEWITHSUNDEEP
mongodb
States
States

Reputation: 548

mongodb schema design collection vs index

I am just experimenting with mongodb/redis for work. I am considering this scenario, assume a blog for example.

I plan on doing the following queries, primarily:

  1. List posts by a specifc user
  2. List comments by a specific user
  3. List posts based on a specific category
  4. View a single post and its comments

Note: Redis is used to store userid<->username mapping.

Is this a good/flexible schema design? The future plan say would be to add post/comment rating.

Post

  • _id
  • author (db-ref: user._id; index)
  • content
  • category (index)

User

  • _id
  • username (unique index)
  • passwordhash

Comments

  • _id
  • post (db-ref: post._id; index)
  • author (db-ref: author._id; index)

adding Rating/votes

Post

  • _id
  • author (db-ref: user._id; index)
  • content
  • category (index)
  • votes (number)

User

  • _id
  • username (unique index)
  • passwordhash

Comments

  • _id
  • post (db-ref: post._id; index)
  • author (db-ref: author._id; index)
  • votes (number)

CommentVotes

  • _id = author.Id (key)
  • voted: [comment._id, comment._id, ...]

PostVotes

  • _id = author.Id (key)
  • voted: [post._id, post._id]

What do you think? Or am I just nuts?

Upvotes: 2

Views: 333

Answers (2)

jcollum
jcollum

Reputation: 46609

I think you're still thinking relationally. I like to think of document data objects as Russian dolls with links (threads?) that can link one doll to another. In your case:

  • Users doll
    • Username
    • Email
    • PasswordHash
    • PostUpvotes (list of Post IDs)
    • CommentUpvotes (list of Comment IDs)
  • Posts doll
    • Comments doll (list of comments)
      • Comment
        • User ID
        • Username
        • TotalVotes (int)
        • Comment ID
    • TotalVotes (int)
    • Category IDs (list) (surely a post can have more than one?)
    • Author ID
  • Categories Doll

You might want to put the votes on comments and posts into the user object then use map/reduce to get the counts every 15 mins or so (this is the 'canonical' use of a map/reduce). The important thing about upvotes is that a User doesn't get to do them twice, so keeping them in the User object makes more sense (no hitting of an index to see if the User has voted on a post already). Since the actual number of upvotes per Post isn't as critical, it can be kept in the Post and updated periodically.

Upvotes: 2

William Z
William Z

Reputation: 11129

For a couple of example schema designs that address these issues, see

Upvotes: 1

Related Questions