нужно структурировать мою базу данных Firebase в реальном времени - PullRequest
0 голосов
/ 12 апреля 2020

Мне нужна помощь для структурирования моей базы данных в реальном времени. У меня есть два типа пользователей (пользователи и консультанты). когда пользователь входит в систему, он может видеть счетные категории. (например: семья, образование). когда они выбирают категорию, он перенаправляет их в список онлайн-консультантов в этой выбранной категории, но не показывает ни одного пользователя. Мой вопрос заключается в том, как я могу управлять этими двумя типами пользователей при входе в систему и изменении онлайн-статуса.

{
  "categories" : {
    "EDUCATIONAL" : {
      "description" : "this is educational council",
      "name" : "Educational Counciling",
      "status" : true
    },
    "FAMILY" : {
      "description" : "this is family counciling",
      "name" : "Family Counciling",
      "status" : true
    }
  },
  "chats" : {
    "COUNCILER2" : {
      "jFufY3heXJgHbnuVeA9Ez1zH8ug2" : {
        "MESSAGEID1" : {
          "from" : "them",
          "text" : "Hello how are u"
        },
        "MESSAGEID2" : {
          "from" : "me",
          "text" : "hello from me"
        }
      }
    },
    "jFufY3heXJgHbnuVeA9Ez1zH8ug2" : {
      "COUNCILER2" : {
        "MESSAGEID1" : {
          "from" : "me",
          "text" : "Hello how are u"
        },
        "MESSAGEID2" : {
          "from" : "them",
          "text" : "hello from me"
        }
      }
    }
  },
  "councilers" : {
    "EDUCATIONAL" : {
      "COUNCILER2" : {
        "description" : "peter test description",
        "email" : "peter123@test.com",
        "name" : "peter smith",
        "online" : true,
        "phone" : "0773453323"
      }
    },
    "FAMILY" : {
      "jFufY3heXJgHbnuVeA9Ez1zH8ug2" : {
        "description" : "test description",
        "email" : "johndoe123@test.com",
        "name" : "john smith",
        "online" : false,
        "phone" : "0770230006"
      },
      "COUNCILER3" : {
        "description" : "test description",
        "email" : "willsmith123@test.com",
        "name" : "will smith",
        "online" : true,
        "phone" : "0770230006"
      }
    }
  },
  "users" : {
    "USERID1" : {
      "email" : "kalana123@test.com",
      "name" : "kalana mihiranga",
      "online" : true,
      "type" : "counciler"
    },
    "USERID2" : {
      "email" : "john123@test.com",
      "name" : "john smith",
      "online" : true,
      "type" : "user"
    },
    "jFufY3heXJgHbnuVeA9Ez1zH8ug2" : {
      "email" : "johndoe123@test.com",
      "name" : "john doe",
      "online" : true,
      "type" : "counciler"
    },
    "z5jDI0l1uBcK1RRce1SwMX3RL253" : {
      "email" : "peter123@test.com",
      "name" : "peter john",
      "online" : false,
      "type" : "user"
    }
  }
}

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

1 Ответ

1 голос
/ 12 апреля 2020

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

Это действительно суть вашего вопроса. проблема, и сразу же суть решения.

При использовании базы данных № SQL вы должны смоделировать свои данные, чтобы разрешить ваши варианты использования. Поэтому, если ваша текущая структура не позволяет вам найти категорию для известного счетчика [sic]), вам следует либо изменить структуру, чтобы разрешить это, либо добавить дополнительные данные.

Например, я ' Рассмотрим следующие варианты:

Сохранение получателей в виде списка

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

  "councilers" : {
      "COUNCILER2" : {
        "description" : "peter test description",
        "email" : "peter123@test.com",
        "name" : "peter smith",
        "online" : true,
        "phone" : "0773453323",
        "category": "EDUCATIONAL"
      }
      "jFufY3heXJgHbnuVeA9Ez1zH8ug2" : {
        "description" : "test description",
        "email" : "johndoe123@test.com",
        "name" : "john smith",
        "online" : false,
        "phone" : "0770230006",
        "category": "FAMILY"
      },
      "COUNCILER3" : {
        "description" : "test description",
        "email" : "willsmith123@test.com",
        "name" : "will smith",
        "online" : true,
        "phone" : "0770230006",
        "category": "FAMILY"
      }
  },

Используя указанную выше структуру, вы все равно можете получить счетчики в правильном порядке с помощью firebase.database().ref("councilers").orderByChild("category"), но теперь каждый консультант также может найти свой собственный узел и обновить свой online статус.

Сохранение дополнительного сопоставления от консультанта к его категории

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

Одним из возможных решений является добавление этого указанного c отображения в вашу базу данных в качестве дополнительного топ- список уровней:

"counciler_categories": {
  "jFufY3heXJgHbnuVeA9Ez1zH8ug2": "EDUCATIONAL",
  "COUNCILER2": "FAMILY",
  "COUNCILER3": "FAMILY"
}

Теперь вы можете найти категорию для консультанта, а затем обновить его статус в /councilors/$category/$uid.

Сохранить онлайн-статус отдельно от других данных

Другой вариант - разделить статус на свой собственный узел верхнего уровня, введенный с помощью UID консультанта:

"counciler_online": {
  "jFufY3heXJgHbnuVeA9Ez1zH8ug2": true,
  "COUNCILER2": false,
  "COUNCILER3": true
}

Итак, с помощью этой дополнительной структуры вы удалите online свойство от каждого /councilers/$category/$uid узла, и теперь консультанты могут обновлять только свой статус, когда они в сети.


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

Я настоятельно рекомендую прочитать Нет SQL моделирование данных , смотреть Firebase для SQL разработчиков и Знакомство с Cloud Firestore (последняя относится к другой базе данных, но большая часть рекомендаций в ранних эпизодах в равной степени относится и к другим No SQL базы данных).

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