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:
- List posts by a specifc user
- List comments by a specific user
- List posts based on a specific category
- 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?
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:
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.