Desgin - Should I split or not my data between Documents?

[hblzr]

Hi,

I have being working on design this initial data setup for a forum/board like back-end. The initial engine selected was SQLite so I ended up with 3 main tables:

• Topic
• Thread
• Reply

Where:

• Each Topic can have X number of Threads under it
• Each Thread can have Y number of Replies under it.

For that I end up with Thread having a column (foreign key) to point to a Topic AND Reply also had a column (foreign key) to point to a Thread.

After that I looked-up some No-SQL options and couchdb really caught my eye BUT it also created few questions about what could be a "canonical" (or at least recommended) way to design the data.

The first redesign I though was to just create a Topic document where both Threads and Reply would also be stored as well:

{
  "_id": "bab9325956b6fd77d4dabef508007bfe",
  "_rev": "3-ffcbb18c2d8439ac20b957a4b8092889",
  "name": "foo",
  "threads": [
    {
      "title": "new thread 2",
      "body": "new thread 2 body",
      "replies": [
        {
          "body": "simple comment 1 on thread 2"
        }
      ]
    }
  ]
}

This seemed to be a pretty reasonable design until I realized that I might not able to just append either new Threads or Replies without having to recover and load the entire Topic in-memory.

Then I read little about design documents and the possibility to define/setup views and update functions which leads me to my first question: Would it be possible to leverage a view or an update function to handle a partial update of the entire document?

I then decide that It might be better if I kept the original design idea of splitting the data between three docs. The only "issue" I see with this approach is kinda makes me think that I might not be needing to use NoSQL in the project.

What's is the community opinion on this scenario?

thank you for reading.