Как правильно структурировать данные такого рода в хранилище?

Question

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

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

Я планирую использовать эту структуру для этой цели

Providers ( Collection )
   Provider 1 ( Document )
      Name
      City
      Categories
   Provider 2
      Name
      City

Products ( Collection )
   Product 1 ( Document )
      Name
      Description
      Category
      Provider ID
   Product 2
      Name
      Description
      Category
      Provider ID

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

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

Answer 1

Как правильно структурировать данные такого рода в хранилище?

Вы должны знать, что не существует "идеального", "лучшего" или "правильного" решения для структурирования базы данных Cloud Firestore. Лучшее и правильное решение - это решение, которое соответствует вашим потребностям и облегчает вашу работу. Помните также, что в мире баз данных NoSQL не существует единой "правильной структуры данных". Все данные смоделированы, чтобы разрешить варианты использования, которые требуются вашему приложению. Это означает, что то, что работает для одного приложения, может быть недостаточным для другого приложения. Так что нет единого правильного решения для всех.

То, как вы структурируете свои данные, выглядит хорошо для меня. В общем, есть два способа добиться того же. Первый - сохранить ссылку на провайдера в объекте продукта (как вы это уже делаете) или скопировать весь объект провайдера в документ продукта. Эта последняя техника называется denormalization и это довольно распространенная практика, когда дело доходит до Firebase. Для лучшего понимания, я рекомендую вам посмотреть это видео, Денормализация нормальна с базой данных Firebase. Это для базы данных реального времени Firebase, но те же принципы применимы к Cloud Firestore.

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

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

Поэтому вам следует задать себе несколько вопросов о данных, которые вы хотите дублировать, или просто сохранить их в качестве ссылок:

1. Это статическое или оно будет меняться со временем?
2. Если да, нужно ли обновлять каждый дублированный экземпляр данных, чтобы все они оставались синхронизированными? Это то, что я также упоминал ранее.
3. Когда дело доходит до Firestore, вы оптимизируете производительность или стоимость?

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

При таком подходе вы пишете очень мало дублированных данных (в основном только Provider ID). Это означает, что ваш код для записи этих данных будет довольно простым и довольно быстрым. Но при чтении данных вам нужно будет загрузить данные из обеих коллекций, что означает дополнительный вызов базы данных. Это обычно не является большой проблемой производительности для разумного количества документов, но определенно требует больше кода и большего количества вызовов API.

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

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

Это общее соображение в базах данных NoSQL: вам часто приходится учитывать производительность записи и дисковое пространство, а не производительность чтения и масштабируемость.

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

Так что, в конце, помните, что оба являются правильными подходами, и ни один из них не является лучше, чем другой. Все зависит от того, каковы ваши варианты использования и насколько вы удобны с этой новой техникой дублирования данных. Дублирование данных - ключ к быстрому чтению не только в облачной базе данных Firestore или Fireabase в реальном времени, но и в целом. Каждый раз, когда вы добавляете одни и те же данные в другое место, вы дублируете данные, что повышает скорость чтения. К сожалению, взамен у вас есть более сложное обновление и более высокое использование памяти и памяти. Но вы должны отметить, что дополнительные вызовы в базе данных реального времени Firebase, не дорогие, в Firestore есть. Сколько данных дублирования в сравнении с дополнительными вызовами базы данных является оптимальным для вас, зависит от ваших потребностей и вашей готовности отказаться от "единой точки определения", которую можно назвать очень субъективной.

Закончив несколько проектов Firebase, я обнаружил, что мой код чтения значительно упрощается, если я дублирую данные. Но, конечно, написание кода становится более сложным одновременно. Это компромисс между этими двумя и вашими потребностями, который определяет оптимальное решение для вашего приложения. Кроме того, чтобы быть еще более точным, вы также можете измерить то, что происходит в вашем приложении, используя существующие инструменты, и принять соответствующее решение. Я знаю, что это не конкретная рекомендация, но это разработка softwarte. Все связано с измерением вещей.

Пожалуйста, также посмотрите на мой ответ из этого поста, где я объяснил больше о collections, maps а также arrays в огненном магазине.