8

I'm trying to implement blog post storage using mongo db.

I've got two domain entities:

"Blog post" and "Author"

Currently I've added AuthorId property to blog post entity. Is that the right approach to store relation between objects?

Community
  • 1
  • 1
Alexey Zakharov
  • 24,694
  • 42
  • 126
  • 197

2 Answers2

20

I think this post will be right for you http://www.mongodb.org/display/DOCS/Schema+Design

Use Cases

Customer / Order / Order Line-Item

Orders should be a collection. customers a collection. line-items should be an array of line-items embedded in the order object.

Blogging system.

Posts should be a collection. post author might be a separate collection, or simply a field within posts if only an email address. comments should be embedded objects within a post for performance.

Schema Design Basics

Kyle Banker, 10gen

http://www.10gen.com/presentation/mongosf2011/schemabasics

Indexing & Query Optimization Alvin Richards, Senior Director of Enterprise Engineering

http://www.10gen.com/presentation/mongosf-2011/mongodb-indexing-query-optimization

**These 2 videos are the bests on mongoddb ever seen imho*

kilianc
  • 7,397
  • 3
  • 26
  • 37
9

Currently I've added AuthorId property to blog post entity. Is that the right approach to store relation between objects?

I'd say no. You are "supposed" to store everything you need in a blog document in a denormalized way (e.g. the blog post, the comments, the tags, etc). So if you want to show the Author's name, you should add it to the blog document. This would allow to fetch an entire page's data with a single query, which is kinda the point of a document-oriented database.

Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
  • 6
    renaming a user becomes a very expensive call though! – Blankman Jun 28 '10 at 14:25
  • 2
    @Blankman: True. Still, I think that the philosophy of document oriented db is to fetch a whole document in one query. And by the way, what is the ratio of [renaming a user]/[showing a blog post]? I think it's **very** low. – Pascal Thivent Jun 28 '10 at 14:43
  • @Blankman, You can do it async and updates are very fast in MongoDB because MongoDB has update-in-place. You can also index the blog posts on authorid. – TTT Jun 28 '10 at 15:40
  • 1
    Pascal, yes in this case its low, but say you had to display the user's current points. You'd have to make another call for that as that would become stale very fast potentially. – Blankman Jun 29 '10 at 03:37
  • 1
    @Blankman, That's true, something like the reputation points of a user change often but staleness is often acceptable. – TTT Jun 29 '10 at 07:56
  • As I heard some document oriented db has multi dimensional structure so authorid could be used in both document objects: author and blog post. – Alexey Zakharov Jun 29 '10 at 12:30
  • @Blankman: Well, @TTT gave you a pretty good answer. I'd just add one thing: nothing forces you to use a document oriented db, it won't fit in every situation. – Pascal Thivent Jun 29 '10 at 12:33
  • 1
    TTT staleness is acceptable but not points! Say you are reading a 1 month old post by John Skeet, his points will be WAY off. Points has to be near realtime, maybe 1 hour stale (if that's what you meant that I agree). – Blankman Jun 29 '10 at 14:18
  • 1
    @Blankman, You don't have to see exactly how many points Jon Skeet has. You can show a rounded number, for instance 190k. This means that you only have to update if Jon Skeet gains another 1000 points. – TTT Jun 29 '10 at 16:32