CODEWITHSUNDEEP
.netdatabasedatabase-designravendb
ChadT
ChadT

Reputation: 7693

Document Database Design For Forum

I'm putting together a simple forum as a way to dip my toe into document dbs - thinking that it would be relatively straight forward thing to model.

I'm having trouble figuring out exactly how the documents should be stored. Using RavenDB at the moment but I'd imagine it's going to be similar for other doc. dbs.

So basically, there are Forums and each forum has a bunch of Threads and each thread contains a bunch of Posts which are authored by Users.

In my head I have it plotted out as having each of these be distinct documents, mainly because each Forum could have thousands of Threads, and each Thread could have thousands of Posts. Having non-distinct documents it seems would cause them to become massive over time?

When viewing a page that lists all the Posts I want to display the Author name (no big deal) and the Author post count. Here is where I'm stuck.

I can store the Author name in the post as it's unlikely to change, however the Author post count is going to constantly change, so this cannot be stored within the Post.

So now if I'm displaying a page with 50 posts, I need to perform the relational equivalent of a join to get the current Author post count. This indicates to me I'm doing it wrong, unless a document DB is just not a good fit for this scenario?

Edit

Looks like Live Projections in RavenDB should handle this just fine but I'd still like to field some comments on possible alternative DB designs.

Upvotes: 2

Views: 555

Answers (1)

NicoGranelli
NicoGranelli

Reputation: 680

I was thinking about a really similar situation. And I came up with the same conclusion as you. But, I was forgetting something, and maybe you're also forgetting the same: Document DB have a very denormalized nature. So, you can use live projections in ravenDB, but for special cases, because the normal thing to do is duplicate the data. For example:

Post:

  • ThreadId (needed for filtering)

  • Text

  • AuthorId

  • AuthorUsername

  • AuthorLastLogin

  • AuthorAnything

In this way, you have the author's id if you need it later, but you have the most used data denormalized and available without joins or live projections.

In the case of author post count, you have to use a map/reduce index. Those index are continusly regenerating. So, when an author make a post, his count wont be updated right away, but it will be eventually consistent. That's is an important part of Document DB.

Hope this could help

Upvotes: 1

Related Questions