Рекомендация по структуре данных noSQL для организационных приложений - PullRequest
Новая
       10

Рекомендация по структуре данных noSQL для организационных приложений

0 голосов
/ 30 января 2019

Я перепроектирую свою структуру данных для организационного приложения. Проблема состоит в том, чтобы найти оптимальную структуру и сводится к индексации и поддержанию гибкости структуры.Он основан на структуре JSON и начинается с вопроса карты объектов или массива объектов.[{}] против {{}}.Должен ли каждый объект верхнего уровня индексироваться по ключу или ключ должен находиться внутри объекта, и индекс создается отдельно).

Приложение содержит пользовательские задачи, встречи, события и заметки.Я использовал Localstorage на клиенте и mongoDB на сервере.Для клиента я перехожу на IndexedDB и воспользуюсь этой возможностью, чтобы также изменить дизайн моей локальной структуры данных JSON.

При использовании API календаря Google я заметил, что многие из результатов - это просто случайный список календаря.События.Список представляет собой массив объектов, которые имеют соответствующую информацию о событии.Конечно, это результат запроса REST, а не собственно структура хранения данных, однако это заставило меня задуматься ... ранее мои данные были всеми парами ключ: значение, иногда вложенными, но всегда начинающимися с ключа.{{}}

Например, используя ключ startTime, представленный номером эпохи (или может быть строкой isoDateTime): {{}} 

"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)
    }
    ...
]

Во-первых, я легко могу получить диапазоны дат событий, проверить, существует ли событие определенного дня, получить все ключи и т. Д. Я могу сохранить их в localalstorage или mongodb напрямую, используя свой уникальный ключ.У меня также есть генератор ключей, который увеличивает ключ isoDateTime (в случае, если они могут перекрываться, эпоха javascript использует миллисекунды, поэтому существует 1000 различий в секунду, поэтому я не беспокоюсь о перекрывающихся ключах).Проблема: если я изменю время начала события, мне нужно будет изменить свой ключ или сгенерировать новый объект с правильным ключом.В целом кажется эффективным, но хрупким подходом.

Во втором, при инициализации приложения, я мог бы запустить функцию индексации, которая упорядочивает по startDateTime и каждый указывает на связанный объект.Для сохранения в хранилище было бы немного интереснее, поскольку у меня нет очевидной пары ключ / значение.Я мог бы сохранить массив под ключом «события», но я не уверен, как будут работать обновления, если только я не сохранил индекс по всем позициям массива.Это может быть более гибким, поскольку я могу легко изменить свое поле startTime, и у меня может быть несколько индексов, которые также могут быть легко изменены.

Итак, два вопроса: во-первых, между двумя опциями, {{}} и[{}], который является наиболее рекомендуемым подходом для сохранения вложенных данных, которые необходимо проиндексировать.Во-вторых, я сохраняю все данные dateTime в формате UTC (меняется на клиенте при рендеринге в локальный часовой пояс). Должен ли я использовать строку isoDateTime или, может быть, просто номер Epoch?

Любые рекомендации или отзывы очень приветствуютсяуже несколько дней пишу разные сценарии и алгоритмы.Я действительно хочу сделать это правильно.

Спасибо, Пол

1 Ответ

0 голосов
/ 30 января 2019

Мой первый инстинкт - создать хранилище событий.Дайте каждому событию автоматически увеличенный идентификатор.Для каждого события убедитесь, что вы храните несколько базовых свойств, таких как дата начала, дата окончания и т. Д. Затем для конкретных запросов, которые вы хотите выполнить, и надеетесь на их быстрое выполнение, создайте индексы для соответствующих свойств.

События будут отсортированы по id при итерации по хранилищу, но будут отсортированы по дате или любым другим при итерации по индексу.

Если вы хотите экспортировать в json, вы должны экспортироватьобъект, содержащий массив объектов событий.

Для nosql не важно, чтобы каждое событие имело одинаковые свойства.Важны только сам тип объекта и минимальный набор свойств, таких как путь к ключу.Остальные свойства являются полностью переменными, и их следует понимать как «мешок» разного.реквизит.

Если это не поможет, то, наверное, я неправильно понял вопрос.

...