Recommendation for a noSQL data structure for organizational application - database

Question

I'm redesigning my data structure for an organizational application The problem is trying to come up with the optimal structure and boils down to indexing and keeping the structure flexible. It is based on a JSON structure and starts with the question of a map of objects or an array of objects. [{}] vs {{}}. Should each top level object be indexed by a key, or should the key be inside of object, and an index is generated separately).
The app contains user tasks, appointments, events, and notes. I used Localstorage on the client, and mongoDB on the server. For the client, I'm changing to IndexedDB and will take this opportunity to also redesign my local JSON data structure.
When using the google calendar api, I noticed many of the results are just a random list of calendar events. The list is an array of objects which have relevant event info. Granted, these are the result of a REST request, not the actually data storage structure itself, however it got me to thinking... previously my data was all key:value pairs, sometimes nested, but always starting with a key. {{}}
For example, using a startTime key, represented by an epoch number (or could be isoDateTime string):
{{}}
"events": {
(EPOCH NUMBER): {
creationDate: (EPOCH NUMBER),
UID: (STRING),
summary: (STRING),
endDateTime: (EPOCH NUMBER)
}
...
}
vs
[{}]
"events": [{
startDateTime: (EPOCH NUMBER)
creationDate: (EPOCH NUMBER),
UID: (STRING),
summary: (STRING),
endDateTime: (EPOCH NUMBER)
}
...
]
In the first, I can easily get date ranges of Events, test if an event of a certain day exists, get all keys, etc. I can save to localstorage or mongodb directly using my unique key. I also have a key generator which increments the isoDateTime key (in the case they might overlap, javascript epoch uses milisecond so there are 1000 diff per second so I'm not concerned about overlapping keys). Problem: if I change an event start time, I'd need to change my key or generate a new object with the right key. Overall seems efficient, but a brittle approach.
In the second, on application initialization, I could run an indexing function which orders by the startDateTime and each points to the associated object. To save to storage, it would be a little more interesting since I don't have an obvious key/value pair. I could save the array under the key "events" but i'm not sure how updates would work, unless I also kept an index on all the array positions. This could be more flexible as I can easily change my startTime field, and I could have multiple indexes, which could also easily be changed.
So two questions: First, between the two options, {{}} and [{}] which is the more recommended approach for saving nested data which needs to be indexed. Second, I'm saving all dateTime data as UTC (changing on client when rendering to local Timezone), should I use the isoDateTime string or maybe just the Epoch number?
Any recommendations or feedback greatly appreciated, I've been scribbling different scenarios and algorithms for days now. I really wanna get this right.
Thanks,
Paul

Answer 1

My first instinct is to basically create an object store of events. Give each event an auto-incremented id. For each event, ensure that you store a few basic properties like start-date, end-date, etc. Then, for the particular queries you wish to run and hope for them to complete quickly, create indices on the properties involved.
The events will be sorted according to id when iterating over the store, but will be sorted by date or whatever when iterating over the index.
If you want to export to json, you would export an object containing an array of event objects.
For nosql, it isn't important that each event has the same properties. Only the object type itself, and a minimal set of properties like the key path, are important. The rest of the properties are completely variable, and should be understand as just a 'bag' of misc. props.
If this doesn't help then I guess I misunderstood the question.