What's is recommended for a To-Do List schema design for MongoDB? - mongodb

Question

With the main purpose of posting Tasks, displayed as either 'to-do' or 'done', how would one better structure a NoSQL DB of the following objects:
Datetime Created Not Null
Task ID Not Null
Task ID as a Str Not Null
Task Title Not Null
Task Description
Time &/or Date Due
User Not Null
ID Not Null
ID as a Str Not Null
Name Not Null
Username Not Null
Location
Contacts Count
Date Created Not Null
UTC Offset Not Null
Time Zone Not Null
Geo-Enabled Not Null
Verified
Task Count Not Null
Language Not Null
Geo-Location
Coordinates
Place
Shared with Whom
?
Task Status
Marked Done
Auto-Moved to Done (because datetime-due is passed)
Labeled (True/False)
Edited
Edit Count
Edit Datetime
Deleted
Users can post an unlimited number of Tasks, and Tasks can be shared between users. How is this relationship best captured?
Tasks can be manually 'marked done', or 'auto-labeled' and 'auto-moved-to-done' because the date-time due is passed.
Edits & Deletes are to be recorded as well.
As a starting place, what are the upsides &/or downsides of the following schema (with scalability a prime focus):
{
"created_at":"Day Mon ## 00:00:00 +0000 20##",
"id":#####,
"id_str":"#####",
"title":"This is a title",
"description":"The description goes here..",
"date_due":"Day Mon ## 00:00:00 +0000 20##",
"user":{
"id":####,
"id_str":"####",
"name":"Full Name",
"user_name":"Username",
"location":"",
"contacts_count":101,
"created_at":"Day Mon ## 00:00:00 +0000 20##",
"utc_offset":####,
"time_zone":"Country",
"geo_enabled":true,
"verified":false,
"task_count":101,
"lang":"en",
},
"geo":?,
"coordinates":?,
"place":?,
"shared_with":?,
"moved_done":false,
"marked_done":false,
"edited":false,
"deleted":false,
}

Answer 1

Edits & Deletes are to be recorded as well.
Do you only need to know that a task was altered, not how or by whom?
Otherwise, that will probably require versioning, i.e. for every Task there can be a number of TaskVersions. Alternatively, you could store the modification only - it depends on your needs. In particular, having many writers isn't easy because of locking - what if two people try to change the same object at 'the same time'? You might want to consider optimistic vs. pessimistic locking or mvcc. Be warned that the "Tasks can be shared between users" requirement must be designed carefully.
As a starting place, what are the upsides &/or downsides of the following schema (with scalability a prime focus):
I guess that user refers to the user who logs in. I wouldn't denormalize that information. Suppose a user created a thousand tasks and adds a new contact. Now the contacts_count of 1000 documents must be updated or it will be wrong. Denormalize only what's really necessary, e.g. the user_name.
Depending on what kind of lists you show, you can also choose to only store the user id and actually fetch the user object whenever you need to display the user name. While complex joins aren't supported, doing a $in query on, say 50 or 100 ids (like you would have to query in a list of tasks) is pretty fast.