Блог

У меня есть сомнения относительно того, как структурировать мои данные firestore.

Ежедневно у меня есть такая информация, как:

 TodayDate, From, ToUser1, Subject, Attachment2, AttachmentTypeB
TodayDate, From, ToUser1, Subject, Attachment3, AttachmentTypeA
TodayDate, From, ToUser2, Subject, Attachment4, AttachmentTypeA
TodayDate, From, ToUser2, Subject, Attachment5, AttachmentTypeC

  

Тема и От никогда не совпадают.

Я колеблюсь между двумя структурами, но я готов рассмотреть другой дизайн структуры.

 0/ Root / doc / sub col / sub col fields

1/ users / userid / date / from,subject,etc
OR
2/ reports / date / userid / from,subject,etc 
  

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

Какой ваш совет, пожалуйста?

С уважением,

Джули

Учитывая вашу текущую структуру данных, я предлагаю вам просто использовать cloud firestore вместо базы данных реального времени, поскольку это лучше масштабируется, и вы получаете довольно хорошую производительность при очень низких затратах.

Вы могли бы создать коллекцию, каждая из записей которой содержит перечисленные вами атрибуты: TodayDate, From, ToUser2, Subject, Attachment5, AttachmentTypeC . И его легко запросить, используя where:

 firestore().collection("myCollection").where("subject", "==", subject).get()
  

Смотрите это сравнение.

ОБНОВЛЕНИЕ: Что касается ваших двух вариантов, я не думаю, что все сводится к тому, какой вариант извлекает / обновляет больше / меньше записей. Это зависит от требований вашего приложения / фактического использования. Возможно, вам потребуется извлечь записи для конкретного пользователя, а не только для определенной даты, и наоборот. Итак, обе структуры на самом деле не имеют никакого значения с точки зрения стоимости, если только вы не уверены, что вам никогда не понадобится извлекать записи для каждого пользователя.

Следовательно, я думаю, что основное внимание следует уделять тому, насколько интуитивно понятна и гибка ваша структура и насколько легко ее поддерживать с течением времени. Вам следует рассмотреть возможность отказа от использования вложенных коллекций в первую очередь, поскольку, как представляется (из ваших ежедневных записей), вы могли бы достичь того, что вам нужно, и получить более гибкую структуру с помощью простой коллекции, содержащей документы с необходимыми свойствами. Я думаю, что вложенные коллекции обычно необходимы, когда вы не хотите всегда извлекать все свойства записи или когда вам нужны прослушиватели в реальном времени для определенных свойств, а не для всей записи. Вложенные коллекции на самом деле не увеличивают / уменьшают количество извлекаемых записей, это зависит от фактического использования