Как смоделировать эту структуру данных NoSQL в Firestore (рассмотрите мой первый подход)

Question

Я довольно новый веб-разработчик и мне нужна ваша помощь в проекте, над которым я сейчас работаю. В прошлом я работал над очень простым примером базы данных в реальном времени, и у меня практически нет опыта работы с firestore или NoSql в целом.

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

Каждое утро понедельника задача cron должна искать, какой конечный пользователь подписался на какие панели, а затем объединять данные и отправлять их по электронной почте.

Вопрос в том, как бы вы структурировали данные, чтобы я мог легко составить электронное письмо и отправить его через облачную функцию?

Мой подход состоит в том, чтобы иметь три основные коллекции: RestaurantOwner, EndUser, SpecialOfferings

Пожалуйста, см. Рисунок для примера процесса:

BarOwner и EndUser довольно просты. Однако сложная часть состоит в том, как структурировать SpecialOffers для правильного запроса.

Моя идея состоит в том, чтобы структурировать его на основе календарной недели и связать его с идентификатором пользователя barOwner:

specialOffers: {
    2019_CW27: {
        barUID001: {
            mon: {
                title: 'Banana Daiquir',
                price: 4.99,
            },
            tue: {
                title: 'After Five',
                price: 2.99,
            },
            wed: {
                title: 'Cool Colada',
                price: 6.99
            },
            thu: {
                title: 'Crantini',
                price: 5.99
            },
            fri: {
                title: 'French Martini',
                price: 4.99
            }
        },
        barUID002: {
            mon: {
                title: 'Gin & Tonic',
                price: 8.99,
            },
            tue: {
                title: 'Cratini',
                price: 4.99,
            },
            wed: {
                title: 'French Martini',
                price: 4.99
            },
            thu: {
                title: 'After Five',
                price: 3.99
            },
            fri: {
                title: 'Cool Colada',
                price: 6.99
            }
        }
    },
    2019_CW28: { 
        barUID01: {~~~},
        barUID02: {~~~}
    }    
} 

Недостаток этого подхода заключается в том, что он создает глубоко вложенный объект, когда вы представляете, что существует 52 календарных недели, например 100 подписанных баров по 5 специальных предложений в неделю, и я не уверен, что смогу запросить его как мне нужно.

Является ли этот подход разумным или что бы вы сделали по-другому?

Большое спасибо за вашу помощь! Я высоко ценю это.

Answer 1

Я предполагаю следующие сценарии:

1) Владельцы бара очень часто вносят изменения в свои предложения.

2) Владельцы бара должны быть единственными, кому разрешено изменять предложения каждого бара.

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

Когда использовать вложенные коллекции:

1) Когда в документе много полей. Облачный Firestore имеет ограничение в 20 000 полей. (Если число Bars может превышать более 20 000 полей)

2) При обновлении родительской коллекции это обычная операция. Firestore позволяет обновлять документ только со скоростью 1 запись в секунду. (Если информация SpecialOffers каждой панели изменяется очень часто. Если два владельца бара изменяют свои предложения, только 1 запись успешна, и вторая операция записи ожидает, пока первая не будет завершена. Это может задержать обновления предложений, особенно в конце недели, когда почти все бары обновляют предложения.)

3) Если вы хотите ограничить доступ к определенным полям документа. (Если вы хотите ограничить доступ к предложениям бара только для barOwner. Вы можете ограничить доступ к каждому документу в подгруппе Bars в соответствии с его владельцем, используя Правила безопасности Firestore )

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

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

В конечном итоге выбор зависит от ваших вариантов использования.

Надеюсь, это поможет.