kalana93
kalana93

Reputation: 71

need to structure my firebase realtime database

i need a help for structure my realtime database. i have two user types( users and councilers). when user log in then they can see counciling categories. (eg: family, education). when they select a category it redirects to the list of online councilers in that selected category but not show any user. my question is how can i manage these two types of users when log in and change online status.

{
  "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" : "[email protected]",
        "name" : "peter smith",
        "online" : true,
        "phone" : "0773453323"
      }
    },
    "FAMILY" : {
      "jFufY3heXJgHbnuVeA9Ez1zH8ug2" : {
        "description" : "test description",
        "email" : "[email protected]",
        "name" : "john smith",
        "online" : false,
        "phone" : "0770230006"
      },
      "COUNCILER3" : {
        "description" : "test description",
        "email" : "[email protected]",
        "name" : "will smith",
        "online" : true,
        "phone" : "0770230006"
      }
    }
  },
  "users" : {
    "USERID1" : {
      "email" : "[email protected]",
      "name" : "kalana mihiranga",
      "online" : true,
      "type" : "counciler"
    },
    "USERID2" : {
      "email" : "[email protected]",
      "name" : "john smith",
      "online" : true,
      "type" : "user"
    },
    "jFufY3heXJgHbnuVeA9Ez1zH8ug2" : {
      "email" : "[email protected]",
      "name" : "john doe",
      "online" : true,
      "type" : "counciler"
    },
    "z5jDI0l1uBcK1RRce1SwMX3RL253" : {
      "email" : "[email protected]",
      "name" : "peter john",
      "online" : false,
      "type" : "user"
    }
  }
}

this is my structure look but i have a problem when counciler log in how can i change online status. because i get all councilers list using councilers node and not in users node. when counciler log in i haven't any option to identify which category is he in. so i can't change councilers node online status

Upvotes: 0

Views: 42

Answers (1)

Frank van Puffelen
Frank van Puffelen

Reputation: 598797

when counciler log in i haven't any option to identify which category is he in. so i can't change councilers node online status

This is indeed the crux of your problem, and immediately also the crux of the solution.

When using a NoSQL database you should model your data to allow your use-cases. So if your current structure doesn't allow you to find the category for a known counciler [sic]), then you should either change the structure to allow that, or add additional data.

For example, I'd consider these options:

Store the councilers as a list

At first glance your JSON under councilers seems more deeply nested then needed. If you model it like this:

  "councilers" : {
      "COUNCILER2" : {
        "description" : "peter test description",
        "email" : "[email protected]",
        "name" : "peter smith",
        "online" : true,
        "phone" : "0773453323",
        "category": "EDUCATIONAL"
      }
      "jFufY3heXJgHbnuVeA9Ez1zH8ug2" : {
        "description" : "test description",
        "email" : "[email protected]",
        "name" : "john smith",
        "online" : false,
        "phone" : "0770230006",
        "category": "FAMILY"
      },
      "COUNCILER3" : {
        "description" : "test description",
        "email" : "[email protected]",
        "name" : "will smith",
        "online" : true,
        "phone" : "0770230006",
        "category": "FAMILY"
      }
  },

With the above structure, you can still get the councilers in the correct order with firebase.database().ref("councilers").orderByChild("category"), but now each counselor can also find their own node and update their online status.

Store an additional mapping from counciler to their category

In your current structure you can easily look up the counselors for a specific category. You can't however easily find the category for a specific counselor, which is what you need now.

One possible solution is to add that specific mapping to your database as an additional top-level list:

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

Now you can look up the category for the counselor, and then update their status under /councilors/$category/$uid.

Store the online status separate from the other data

Another option would be to separate out the status into its own top-level node, keyed by the counselor's UID:

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

So with this additional structure, you'd remove the online property from each /councilers/$category/$uid node, and now the counselors can update only their status when they're online.


There are probably even more options than just the three common ones I outlined above, and none of these is pertinently better than the others. You'll have to pick what works for the use-cases in your app, and modify as you go along.

I highly recommend reading NoSQL data modeling, watching Firebase for SQL developers, and Getting to know Cloud Firestore (the latter is for a different database, but much of the advice in early episodes applies equally to other NoSQL databases).

Upvotes: 1

Related Questions