What is the best way to store the amount of time spent (hours : minutes) in MongoDb?

Question

I'm playing with a small web application to store tasks and time spent on a daily basis, and report on it in weekly and monthly reports.

For my back-end I wanted to work with MongoDb but can't immediately find what the best way would be to store the time spent on a task. I have no interest in storing the actual timeframe (start and stop date), just the time spent in hours:minutes.

Since I will be making weekly and monthly reports, I need to be able to calculate the sum on a weekly, monthly basis.

What would be the best way to store the time spent?

I'm leaning towards just storing the amount of minutes in a 32-bit integer and convert it to hours:minutes on the client. (Or better yet, convert it already in a Mongodb Aggregation Query, if that's possible?)

My Task document would look like this then

{
    "task_id": {
        "$oid": "5311a0a4e4b0386017fce592"
    },
    "timeEntry_date": "ISODate('2014-03-02')",
    "timeSpent_minutes": 30
}

Is this the way to go in MongoDb?

Sorry if I'm stating the obvious here, just starting to learn about MongoDB...

Answer 1

As always on MongoDB "It depends on your usage". In MongoDB you should construct your "schema" so that it will describe your application needs and not your data structure.

If your application is write intensive you should have a really fast and simple writing procedure. eg you can store the milliseconds spent and then do the calculations on read

If you want your application to be faster in reads you can have something like

time_spent: {
  hours: 1,
  minutes: 23,
  seconds: 45
}

in your document

PS I think that

"task_id": {
        "$oid": "5311a0a4e4b0386017fce592"
}

would be better as

task_id: "5311a0a4e4b0386017fce592"

Answer 2

Given the requirements as stated, you'll be best served by serving the data as a numerical value. There are far more query and aggregation operators that would be easily used for a numeric value than the few other options that are available.

While you could store the period as a string, it would need to be consistently zero padded to sort correctly. With a string, you could only effectively do exact matches and range queries (find all that are "0030" or between "0015" and "0045" for example).

While you could also store the start and end times and try to calculate the period, it adds unnecessary complication to queries, and in fact may make some types of queries only possible using the aggregation framework. You might find some of the ideas here interesting depending on your needs as well.

The absolute performance difference between any option where the time length is directly stored as a value rather than computed is not likely to be measurable, as they would consume nearly the same amount of space for each option. If you're concerned about absolute disk space usage, I'd suggest you consider using shorter field names. Every document contains the full field name. Some drivers for Mongo provide a handy way of using an alias for field names (by keeping the name you use in code friendly and using a shortened version n the stored document).

I'd go with storing a integer numeric value that best suits the maximum length of time you'll encounter. You can add an index if it's frequently queried, and easily convert it on the client into something more human friendly.