Я создал организационное приложение и реорганизую способ хранения пользовательских данных в базе данных mongodb на внутреннем сервере.Я копирую данные на стороне клиента через хранилище значений ключей (то есть localStorage).
Моя дилемма заключается в сохранении записей в mongoDB, будь то более плоская / сериализованная структура с большим количеством документов на высоком уровне или полностью иерархическая, более глубокая.
Например,на верхнем уровне - задачи, встречи, журнал и события.Под каждым из них находятся ключи строки даты, то есть 2019-02-22, и под ними много данных.
tasks={},
appts={},
journal={},
events={}
tasks[DateKey]=[{
descr: (String)
cDate: (String)
}]
appts[DateKey] = {(time:minutes):{
descr: “gym”,
eTime: (number: minutes)
tZ: (number: minutes)
rmdrs: [30]
uID: (string)
}]
journal[DateKey] = [{
text:(long string),
}]
events[DateKey] = [{
descr: “6 month Anniversary”,
duration: (number: days)
uID: (String)
rmdrs: [30]
}]
Плюсы: работая с данными на стороне клиента, я могу легко получить ключис Object.keys или для циклов для итерации по каждому типу данных, задачам и т. д. Кроме того, он довольно легко перейдет в пригодный для использования формат с помощью JSON.parse.
-
Нас другой стороны, я мог бы также комбинировать ключи типа и даты, чтобы также иметь намного больше сериализованных данных на верхнем уровне, например:
tasks_(DateKey)=[{
descr: (String)
cDate: (String)
}]
appts_(DateKey) = {(time:minutes):{
descr: “gym”,
eTime: (number: minutes)
tZ: (number: minutes)
rmdrs: [30]
uID: (string)
}]
journal_(DateKey) = [{
text:(long string),
}]
events_(DateKey) = [{
descr: “6 month Anniversary”,
duration: (number: days)
uID: (String)
rmdrs: [30]
}]
Все эти dateKeys были бы строками, как для ключа верхнего уровняbe tasks_2019-02-22 = [...] и т. д.
плюсы: Легко / быстрее создавать обновления путем прямой замены документа, а не дополнительной записи внутри документа большего размера?Имеет значение для нескольких атомарных операций одновременно, по сравнению с несколькими документами большего размера, как указано выше.
минусы: с ними не так легко работать, например, нелегко получить все ключи даты для задач без цикловхотя все записи и построение индекса даты ключей задачи.То же самое для любого другого компонента (приложения, события и т. Д.).Не так просто работать на стороне клиента без перевода структуры.
Я должен представить, что это общая проблема при проектировании баз данных, много записей по сравнению с большими / более глубокими.Также я понимаю, что это зависит от варианта использования и данных.В этом случае это для пользовательских записей, которые будут иметь несколько обновлений для синхронизации с клиентскими записями в веб-браузере.
Я ценю любой совет, Пол