Skip to content

Realtime Database

Realtime Database позволяет хранить данные в виде большой сетевой структурной переменных.

Note

Если вы не уверены, что следует использовать: Firestore или Realtime Database, прочтите официальное сравнение. </ note >

Сравнение со структурными переменными

Все данные хранятся в дереве JSON, которое можно сравнить с структурной переменной. Однако есть несколько ключевых отличий:

Доступ детей(child variable)

В отличие от переменных GDevelop, где вы получаете дочерний элемент через <structureVariable>. <childVariableName>, в базе данных Realtime вы получаете его через косую черту: <переменная структуры> / <имя переменной ребенка>. Это означает, что для динамического доступа вы должны написать имя пути как " structure / "+ VariableString (dynamicVariableAccess) +" / specificProperty ", в отличие от структур GDevelop, где вы пишете это так: Переменная (структура [VariableString (dynamicVariableAccess)]. SpecificProperty)

Глубина вложенности дочерних элементов

Хотя в GDevelop нет фиксированного ограничения на глубину вложенности дочерних элементов, Realtime Database не позволяет вам иметь глубина больше 32.

Структурирование данных

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

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

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

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

Регулирование доступа

Возможно, вы не захотите позволять всем писать все. В противном случае каждый может изменять данные других людей! Чтобы выбрать, кто и как может получать доступ, в Firebase есть система правил. Он взаимодействует с Firebase аутентификацией, поэтому вы можете написать это правило, чтобы разрешить аутентифицированные пользователям записывать переменную authonly базы данных: 

{
  "rules": {
    "users": {
      "$uid": {
        ".read": true,
        ".write": "auth != null"
      }
    }
  }
}

Вы также можете иметь переменную со всеми пользователями и иметь для каждого дочернего элемента (названного в честь uid пользователя) свои разрешения в виде карты. Здесь, например, вы можете разрешить каждому пользователю с подтвержденным разрешением получить доступ к собственному документу в переменной userdata, и каждый администратор для доступа к документам в коллекции globaldata: 

{
  "rules": {
    "userdata": {
      "$uid": {
        ".read": true,
        ".write": "auth != null && root.child('permissions').child(auth.uid).child("verified").val() == true"
      }
    },
    "globaldata": {
      "$uid": {
        ".read": true,
        ".write": "auth != null && root.child('permissions').child(auth.uid).child("admin").val() == true"
      }
    }
  }
}

Чтобы узнать подробнее, как писать правила, прочтите руководство по синтаксису, руководство по написанию условий и справочный документ.