How to best store IDs of other database objects within Firebase (Ex: Event with Users)

Question

I am new to firebase, and am building an android app to practice. My app is very straightforward. There are Users, who can create an Event. Other users can either accept or reject an invitation to an Event. To keep things simple, whenever an Event is created, all Users in the database get invited to that Event.

My database is currently structured like this:

What I want to do now is for each Event, I want to know which Users have accepted, declined, or are yet to respond to the invitation.

I am unsure the best way to approach this. These are some ideas I have had:

1. For an Event, create 3 children which will store all the User information for each response option. (accepted, rejected, pending).

2. For an Event, create a child 'responses' which will have each Users uid as a key, and the value could be either "accepted", "rejected", or "pending".

3. Something else completely.

Option 1 seems like it can work, however it means that a User data is going to be copied all over the database. If a User is invited to 1000 events, there will be a copy of that User literally 1000 times, once within every Event.

Option 2 seems logical to me, however I have tried implementing it and am having difficulties building a firebase Query. If I want all the accepted users, I need to get all the uids of the 'acceptedUsers' child, and then pull out of the 'users' node all the children that match these uids. This doesn't seem to be possible...?

Any help or guidance would be greatly appreciated!!

Answer 1

Option 2 seems most direct to me:

responses
  eventid
    uid1: "accepted"
    uid2: "rejected"
    uid3: "pending"

You will indeed have to load the additional information for each user client-side. This works fine, and performs much better than most developers expect due to the fact that the requests can be pipelined over a single connection. For more on this see my answer here: http://stackoverflow.com/questions/35931526/speed-up-fetching-posts-for-my-social-network-app-by-using-query-instead-of-obse/35932786#35932786

If you'd really prefer not to perform the client-side join, you can store additional data for each response that allows you to display it. If you want to display user names:

responses
  eventid
    uid1
      status: "accepted" 
      displayName: "Ryan Saffar"

This gets closer to Peter's answer, but here we key them off event id and uid.

Answer 2

Try this:

Events
  eventid1
     createdby: userx
     eventname: Party
   eventid2
      createdby: usery
      eventname: Meetup


  AttendancetoEvent
        eventid1
            username: userf
            response: accepted
        eventid1
             username: userg
             response: rejected
         eventid2
             username: userg
             response: accepted

then to get the accepted users, do this:

DatabaseReference ref=FirebaseDatabase.getInstance().getReference().child("AttendancetoEvent");
Query queries=ref.child("eventid1").orderByChild("username").equalTo(accepted);

Answer 3

Well you're doing everything right, just to say. For the Events node, you can use .push() function for random branch name. So let's begin, each User has a UID, alright? User's data is particularly stored there including their name, that's done. Now a user posts an event so push that event to Events, now make an arrayList of user's event in the UID node. So when you upload that event you get it's reference and store it in the UID branch so the user can retrieve all of his events. For accepted, pending or rejected choices , I hope whatever you're building has buttons for these functions. So now onClickListener() store the user's Uid in an arrayList for any of the choices and upload it to the branch of retrieved Event. For that in your Event model class add a String for the path reference, so you can upload the choices there. All done. Now if the user who wants to know who accepted, rejected or have pending choices you can display the user name using UID from the arrayList. I suggest to use uid because just in case if the event uploader wants to get any more of the User data who chose any of the options. I think this will work fine.