Как архитектура данных Firestore для ресторанов

Question

у нас есть приложение для отслеживания заказов для ресторанов, и мы используем Firestore.

У нас есть несколько вопросов об архитектуре базы данных. Как хранить данные?

В настоящее время мы храним заказы следующим образом:

сервер / {restaurant} / orders / {OrderID}

Каждый заказ document содержит параметр tableName, и мы запрашиваем его с полем tableName, когда принимаем заказы для таблицы и оплачиваем таблицу.

Должна ли это быть правильная архитектура?

server / {restaurant} / таблицы / {TableID} / заказы / {OrderID}

сервер / {restaurant} / таблицы / {TableID} / платежи / {paymentıd}

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

В ресторане много столов, в этих таблицах есть заказы и платежи, вот как это работает ...

Answer 1

Это очень мнительный и специфичный для приложения c вопрос.

С Firestore / No SQL Я предлагаю сначала создать прототип вашего приложения с точки зрения пользователя. Каковы различные экраны и связанные данные на каждом экране. Это поможет вам определить различные запросы и операции чтения / записи, которые часто выполняются, и как лучше структурировать ваш пожарный склад.

Например: возможно, вы храните заказы таблиц в отдельных уникальных документах, но также один из экранов содержит «сводку заказов», где пользователь может просматривать предыдущие 100 заказов. Это требование может диктовать, что вы также хотите включить сводный документ, содержащий эти предыдущие заказы, чтобы при просмотре пользователем вашего сводного экрана вам не платили 100 операций чтения, а вместо этого только 1.

• Начните с создания прототипа ваших представлений
• Определите модель данных для каждого представления
• Определите запросы, которые вам понадобятся для выполнения
• Начните собирать инфраструктуру базы данных, которая является производительной для вышеупомянутого требования