Предлагаемый способ структурирования базы данных Firestore для глубоко вложенного набора объектов, подобных электронной таблице

Question

Мое приложение используется для создания производственных бюджетов для сложных проектов (строительство, средства массовой информации и т. Д. c.)

Структура бюджета следующая: бюджет содержит «разделы», разделы содержат «учетные записи», учетные записи содержат «субсчета», субсчета содержат позиции. У отдельных позиций есть несколько полей (единицы, курс, валюта, налог и т. Д. c.) И рассчитанная общая сумма

. Или, возможно, использование Firestore для выполнения этих каскадных расчетов является неправильным подходом? Я должен просто загрузить один сложный бюджетный документ в свое приложение, выполнить все расчеты и обновления на клиентах, а затем записать весь бюджет в виде одного документа, когда пользователь нажимает «сохранить бюджет»?

Определенно поля в позициях могут иметь буквенные коды c, которые представляют числовые значения c, которые пользователь может использовать вместо жестко заданного числа, например, пользователь может ввести "= build-week" и определить это с помощью формулы, которая оценивается как "7", что затем используется при расчете итогов.

Позиции всплывают по их итоговым значениям, поэтому итоговые суммы субсчетов равны сумме их позиций, итоговые суммы счетов равны сумме их субсчета, итоги разделов равняются сумме итогов счетов, а итоги бюджета - итоги итогов раздела.

Вопрос о том, как объединить эти данные в документы, составляющие бюджет. Бюджеты могут быть длинными, скажем, 5000 строк или более. Отдельные учетные записи могут иметь сотни позиций.

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

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

Это не так сложно, если каждая позиция - это отдельный документ, я могу просто найти в коллекции наличие кода, пересчитать позицию и использовать облачную функцию, чтобы вспомнить возможные изменения.

Но если все Строковые элементы содержатся в массиве карт внутри каждой карты субсчета. Эм, кажется, что будет довольно утомительно находить и менять их, когда это необходимо ..

С другой стороны - держать эти документы такими маленькими, кажется, что многие документы читают, когда кто-то просматривает бюджет, или, скажем, распечатка. Если кто-то просто нажимает на несколько учетных записей, это может быть 100-е считываний за клик для извлечения всех позиций и сотни или тысяча записей, когда кто-то меняет значение часто используемого именованного значения, такого как «сборка». -weeks ".

Есть ли у кого-нибудь мысли по поводу очевидного" правильного "ответа на этот вопрос? Или это просто зависит от того, для чего я хочу оптимизировать - затраты на пожарные, отзывчивость приложения, сложность кода?

Answer 1

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

Однако есть несколько моментов, которые необходимо учитывать при принятии решения:

• Документы в Firestore имеют ограничение 1 МБ / документ;

• Документы в Firestore имеют ограничение 20000 полей;

• Запросы мелкие, поэтому вы не можете получить данные из подколлекций по одному и тому же запросу;

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

Для рассмотрения 3 это означает, что вы Если вы решите получить все данные для своих разделов, разделенных на под-документы, вам придется многократно читать, это будет означать более высокую стоимость для вас, но более высокую производительность для пользователей.

Чтобы правильно решить эту проблему, я предлагаю вы говорите с возможными пользователями вашего решения и понимаете проблему, которую вы пытаетесь решить, и что они ожидают от приложения. Также может быть интересно взглянуть на Как структурировать ваши видео и Карты, массивы и вложенные коллекции видео, так как они более наглядно объясняют, как Firestore ведет себя и как может помочь в решении проблем, которые может вызвать выбранный вами подход.

Надеюсь, я смог помочь с этими соображениями.