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

with main purpose of posting tasks, displayed either 'to-do' or 'done', how 1 better structure nosql db of following objects:

• datetime created not null
• task id not null
• task id str not null
• task title not null
• task description
• time &/or date due
• user not null
  • id not null
  • id 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 whom
  • ?
• task status
  • marked done
  • auto-moved done (because datetime-due passed)
  • labeled (true/false)
  • edited
  • edit count
  • edit datetime
  • deleted

users can post unlimited number of tasks, , tasks can shared between users. how relationship best captured?

tasks can manually 'marked done', or 'auto-labeled' , 'auto-moved-to-done' because date-time due passed.

edits & deletes recorded well.

as starting place, upsides &/or downsides of following schema (with scalability prime focus):

{    "created_at":"day mon ## 00:00:00 +0000 20##",    "id":#####,    "id_str":"#####",    "title":"this 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, } 

edits & deletes recorded well.

do need know that task altered, not how or whom?

otherwise, require versioning, i.e. every task there can number of taskversions. alternatively, store modification - depends on needs. in particular, having many writers isn't easy because of locking - if 2 people try change same object @ 'the same time'? might want consider optimistic vs. pessimistic locking or mvcc. warned "tasks can shared between users" requirement must designed carefully.

as starting place, upsides &/or downsides of following schema (with scalability prime focus):

i guess user refers user logs in. wouldn't denormalize information. suppose user created thousand tasks , adds new contact. contacts_count of 1000 documents must updated or wrong. denormalize what's necessary, e.g. user_name.

depending on kind of lists show, can choose store user id , fetch user object whenever need display user name. while complex joins aren't supported, doing $in query on, 50 or 100 ids (like have query in list of tasks) pretty fast.