I am assembling an easy forum in an effort to dip my foot into document dbs - convinced that it might be relatively easy factor to model.

I am getting trouble determining how the documents ought to be saved. Using RavenDB right now but I'd imagine it will likely be similar for other doc. dbs.

So essentially, you will find Forums and every forum has a lot of Threads and every thread consists of a lot of Posts that are written by Users.

During my mind I've it plotted out as getting all these be distinct documents, due to the fact each Forum might have 1000's of Threads, and every Thread might have 1000's of Posts. Getting non-distinct documents it appears would cause them to massive with time?

When viewing a webpage that lists all of the Posts I wish to display the Author title (no large deal) and also the Author publish count. Here's where I am stuck.

I'm able to keep Author title within the publish as it is unlikely to alter, nevertheless the Author publish count will constantly change, which means this can't be saved inside the Post.

Now if I am exhibiting a webpage with 50 posts, I have to carry out the relational same as a join to obtain the current Author publish count. This signifies in my experience I am doing the work wrong, unless of course a document DB is simply not a great fit with this scenario?

Edit

Appears like Live Projections in RavenDB should handle this all right but I'd still prefer to area some comments on possible alternative DB designs.

I believed in regards to a really similar situation. And That I emerged with similar conclusion while you. But, I had been failing to remember something, and perhaps you are also failing to remember exactly the same: Document DB possess a denormalized character. So, you should use live forecasts in ravenDB, however for special cases, since the normal factor to complete is duplicate the information. For instance:

Publish:

  • ThreadId (required for blocking)

  • Text

  • AuthorId

  • AuthorUsername

  • AuthorLastLogin

  • AuthorAnything

In by doing this, you will find the author's id if you want it later, but you will find the most used data denormalized and available without joins or live forecasts.

Within the situation of author publish count, make use of a roadmapOrdecrease index. Individuals index are continusly regenerating. So, when a writer create a publish, his count will not be up-to-date immediately, but it will likely be eventually consistent. That's is an integral part of Document DB.

Hope this might help