Правильный способ хранения пользователей в базе данных Firebase

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

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

{
  "users": {
    "alanisawesome": {
      "nickname": "Alan The Machine"
    },
    "gracehop": {
      "nickname": "Amazing Grace"
    }
  }
}

В приведенном выше примере из документации Firebase Legacy они хранят пользователей по именам пользователей. Еще в другом примере я обнаружил следующее:

{
  "users": {
    "123": {
      "name": "Kato"
    },
    "234": {
      "name": "Anant"
    }
  }
}

Здесь они хранят пользователей с UID. Тогда вы можете простоpush() новые пользователи, и их идентификаторы являются случайными ключами, такими как следующие-JRHTHaKuITFIhnj02kE.

Что из перечисленного является лучшим способом хранения пользователей? Имя пользователя, пользовательский UID или случайно сгенерированный ключ?

Ответы на вопрос(1)

Решение Вопроса

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

Но когда у предметов есть естественный ключ, обычно лучше хранить их под этим естественным ключом. У пользователей есть уникальный идентификатор, обычно называемый ихuid, Если у вас нет причин не делать этого, храните пользователей под ихuid, Храня их под своимuidВы можете легко найти данные для данного пользователя:ref.child('users').child(user.uid), Если вы храните пользователей в сгенерированном ключе (например, push-идентификаторе), вам нужно выполнить запрос, чтобы найти ту же запись.

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

 Michael Jones09 авг. 2016 г., 17:42
Здравствуйте, спасибо, это имеет смысл!
 Sistr09 авг. 2016 г., 17:18
я мог быопределенно перейти на пользователяuid как ключ. Бонус: при необходимости это делает защиту данных пользователя с использованием правил Firebase чрезвычайно простой, как вы можете видеть здесь:firebase.google.com/docs/database/security/... .
 George Chalhoub20 июн. 2017 г., 06:00
Очень полезно, спасибо!

Ваш ответ на вопрос