Database structure help, reference vs embedded values?


I’m trying to make some sort of issue tracking functionality in my app.

Each “Issue” object has many “Tasks” inside of it. Each “Task” also has many “Sub Tasks”.

So currently what im planning to show on the page is all my “Issues” and its % completion. The % completion is based upon how many sub tasks are done.

Here are my approaches and the negatives about them:

  1. Not embedded
    In this approach, I’ll have to do this:
for all Issues
   for all Tasks
     for all SubTasks

That means ill have to load/subscribe to 3 databases. Its more easier, but this can take up more bandwidth (which might cost me more money) and it might be slower too for the user


  1. Embedded
    I just loop through all Issues, and check a variable inside each Issue. It might require more space on the db, for 2 extra ints, and it requires that I manually update this value whenever theres a change in each Issue’s Tasks, and each Subtask of those tasks, (which already sounds complicated and a lot of work for me), BUT, its faster to load.
    It may also require less bandwidth (initially), because my understanding of Meteor is that if you don’t need the data yet, then you don’t get it. So opening this page containing all the Issues will essentially give me in my local-db, just the Issues. In my first approach, the moment I load the page, I’d have information on almost everything. even if I haven’t or don’t plan to open up or view the Task page, which will contain its data.

I hope I explained this correctly. Which one is better overall, and specifically for meteor?


Do you need to understand tasks or sub tasks across Issues?

If not go embedded IMO. Treat an issue as a well formed document- mongo is great for that.

If so, then you might want to keep them in seperate collections. Or maybe issues are separate from tasks and sub tasks.

Of course it all depends on your requirements.

Be wary of treating a document DB like Mongo as relational though. It might not end well.