Firestore: как обеспечить единообразие данных между пользователем и документами, содержащими информацию о пользователе? - PullRequest
0 голосов
/ 07 мая 2020

Сводка

Как я могу смоделировать свою базу данных в Firebase, чтобы, например, обзоры на определенной c странице обновлялись информацией о пользователях, то есть если пользователь меняет свой аватар или имя, обзоры также должны отображать обновленные данные пользователя. Большую часть времени я использовал MongoDB с Mon goose, а сейчас я работаю над мобильным приложением с Firebase. В Mon go я просто сохраню ссылку на пользователя в обзоре и заполню поле, чтобы получить данные, которые мне нужны из документа. Есть ли что-то подобное в Firebase и является ли это хорошей или приемлемой практикой?

Быстрые вопросы

  1. Есть ли что-то вроде «.populate ()» в Firebase?
  2. Следует ли мне моделировать документы в максимально возможной степени, чтобы иметь данные, которые будут использоваться в view, и избегать «объединений»?

Пример

Мы иметь коллекцию пользователей и коллекцию магазина с отзывами в ней.

Насколько я читал, вы должны минимизировать чтение do c, и поэтому мы должны моделировать наши данные со спецификациями c значения, которые нам нужны для view, где они будут использоваться, так что нам нужно выполнить только один запрос.

Для упрощения скажем:

У пользователя есть имя, адрес электронной почты, аватар

users: {
    user_id_1: {
        email: "user1@gmail.com",
        name: "John Doe",
        avatar: "some_firestore_url"
    }
}

Если в коллекции магазина:

  1. Есть вложенная коллекция отзывов, подобная этой
stores: {
    store_id_1: {
        name: "Dat Cool Store!",
        reviews: {
            user_id_1: {
                name: "John Doe",
                avatar: "some_firestore_url",
                text: "Great store love it!",
                timestamp: "May 07, 2020 at 03:30"
            }
        }
    }
}

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

Укажите user_id в поле и запросите информацию о пользователе после:
stores: {
    store_id_1: {
        name: "Dat Cool Store!",
        reviews: {
            review_id_1: {
                user: "user_id_1",
                text: "Great store love it!",
                timestamp: "May 07, 2020 at 03:30"
            }
        }
    }
}

Это имитация способа, которым я бы сделал в MongoDB.

Извините, если это звучит сбивающе с толку, или я не объяснил себя наилучшим образом, но здесь 4 часа утра, и я просто пытаюсь понять это правильно :)

Ответы [ 2 ]

0 голосов
/ 07 мая 2020

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

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

В понедельник go Я бы просто сохранил ссылку на пользователя в обзоре и заполнил поле для извлечения данные, которые я хотел из документа. Есть ли что-то подобное в Firebase и является ли это хорошей или приемлемой практикой?

Да, есть. Согласно официальной документации, касающейся типов данных, поддерживаемых Firestore , DocumentReference является одним из них, что означает, что вы можете хранить только путь к документу, а не весь документ. В мире No SQL довольно часто дублируются данные, поэтому одни и те же данные хранятся более чем в одном месте. Опять же, не зная варианта использования вашего приложения, трудно сказать, лучше ли использовать нормализацию, чем хранить только ссылку. Для лучшего понимания я рекомендую вам прочитать мой ответ из следующего сообщения:

И чтобы ответьте на ваши вопросы:

  1. Есть ли что-то вроде «.populate ()» в Firebase?

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

Следует ли мне моделировать документы в максимально возможной степени, чтобы иметь данные, которые будут использоваться в представлении, и избегать «объединений»?

Да, вы должны хранить только те данные, которые вы на самом деле должны отображаться в ваших представлениях. Что касается предложения JOIN, в Firestore не поддерживается что-то подобное. Запрос может одновременно получать документы только из одной коллекции. Если вы хотите получить, например, данные из двух коллекций, вам нужно будет выполнить как минимум два запроса.

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

Другая информация, которая может быть полезна, объясняется в моем ответе из следующего сообщения:

Где вы можете найти лучший способ сохранения данных в документе, коллекции или вложенной коллекции.

0 голосов
/ 07 мая 2020

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

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

{
  "store_id_1": {
    "name": "Dat Cool Store!",
    "reviews": [
      {
        "user_id_1": {
          "name": "John Doe",
          "avatar": "some_firestore_url"
        },
        "text": "Great store love it!",
        "timestamp": "May 07, 2020 at 03:30"
      },
      {
        "user_id_2": {
          "name": "John Doe 2",
          "avatar": "some_firestore_url 2"
        },
        "text": "Great store love it! TWO",
        "timestamp": "May 27, 2020 at 03:30"
      }
    ]
  }
}

Итак, теперь вы можете встроить всю информацию о пользователе в коллекцию stores. Это также уменьшит количество операций чтения.

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

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

...