Как я должен использовать идентификаторы в базе данных Firebase - PullRequest
0 голосов
/ 28 сентября 2018

Привет, товарищи по разработке Firebase!

Ранее в этом году меня наняли на работу в стартап, и мы приступили к разработке нашего приложения на xamarin, и мы решили использовать Firebase в качестве нашего бэкэнда.Решение, которое я в некотором смысле сожалею, так как оно не совсем подходит для .net / xamarin, как, например, Azure.

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

На данный момент наша база данных в реальном времени структурирована следующим образом:

-posts
   -id
      -id
      -title
      -content
      -etc

 -user-profiles
    -id
       -id
       -name
       -age
       -etc

Так что я в основном храню Id для каждого предмета дважды.Во-первых, хотя сохранение поля id как для каждого объекта было бы практичным, потому что, когда я десериализую json в объекты .net, у меня есть свойство ID в каждой из моих моделей, чтобы упростить мою бизнес-логику.

Но ни одна изПримеры firebase используют эту логику, ни какие-либо сторонние учебные пособия.

Есть ли какая-нибудь более чистая структура базы данных, которую я мог бы использовать?Ура и спасибо заранее!

Ответы [ 2 ]

0 голосов
/ 28 сентября 2018

Таким образом, я в основном храню Id для каждого элемента дважды.

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

Я обычно предпочитаю либо хранить моментальный снимок (чтобы я мог получить ключ оттуда), либо вводить ключ в объект данных сразу после десериализации DataSnapshot в такой объект данных.Пример этого (в Android) см. Есть ли способ сохранить ключ в классе, который я использовал из объекта Firebase?

0 голосов
/ 28 сентября 2018

Ну, и posts, и user-profiles должны быть коллекциями, но, как вы реализуете, RTDB будет работать с ним как с объектами.Лично я использую тот же подход, что и ваш, и это из-за того, как работает RTDB - вы можете отправить путь непосредственно к нему и получить нужные данные.Другая альтернатива будет храниться как массив, но вы потеряете контроль над этими парнями - не обязательно, но это не так интуитивно понятно, как хранить его внутри большого объекта и извлекать его по его идентификатору, когдаобязательно.

Если вы беспокоитесь о дублировании ваших данных, вы можете реализовать способ справиться с этим при чтении / записи в коде " front-end ".

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...