Top questions from Stack Overflow and Twitter with Frank van Puffelen - #AskFirebase

By: Firebase

164   3   3892

Uploaded on 01/25/2017

Add the #AskFirebase playlist: https://goo.gl/W3Jm9b
Subscribe to the new Firebase Channel: https://goo.gl/9giPHG

We cover how to create users from the command line interface, modeling many-to-many relationships in Firebase Database, and the Firebase in a Weekend Udacity course.

Questions from this episode:

1:01 - Which Firebase CLI is equivalent to auth.createUserWithEmailAndPassword()? Read more: https://goo.gl/l4Jzkm

1:58 - How to retrieve data from firebase database without DataSnapshot? Learn more about the Udacity course: https://goo.gl/72WB4P

2:45 - How do you model many-to-many relationships in Firebase? Read the Stack Overflow question and response here: https://goo.gl/zsSLmi

Here is the link to David East's "The Firebase Database for SQL Developers": https://goo.gl/o7Bjs5

5:03 - I hardly ever see you anymore, Frank. How can I see more of you? Learn more about the Udacity course: https://goo.gl/72WB4P

Add the Firecasts playlist! https://goo.gl/n2XqG1

Music by http://terramonk.com

Comments (7):

By anonymous    2017-09-20

The self-answer is indeed one way of modeling this. It's probably the most direct equivalent of how you'd model this in a relational database:

  • contractors
  • companies
  • companyAndContractorsAssignment (the many-to-many connector table)

An alternative would be to use 4 top-level nodes:

  • contractors
  • companies
  • companyContractors
  • contractorCompanies

The last two nodes would look like:

companyContractors
    companyKey1
        contractorKey1: true
        contractorKey3: true
    companyKey2
        contractorKey2: true
contractorCompanies
    contractorKey1
        companyKey1: true
    contractorKey2
        companyKey2: true
    contractorKey3
        companyKey1: true

This bidirectional structure allows you to both look up "contractors for a company" and "companies for a contractor", without either of these needing to be a query. This is bound to be faster, especially as you add contractors and companies.

Whether this is necessary for your app, depends on the use-cases you need, the data sizes you expect and much more.

Recommended reading NoSQL data modeling and viewing Firebase for SQL developers. This question was also featured in an episode of the #AskFirebase youtube series.

Update (2017016)

Somebody posted a follow-up question that links here about retrieving the actual items from the "contractors" and "companies" nodes. You will need to retrieve those one at a time, since Firebase doesn't have an equivalent to SELECT * FROM table WHERE id IN (1,2,3). But this operation is not as slow as you may think, because the requests are pipelined over a single connection. Read more about that here: Speed up fetching posts for my social network app by using query instead of observing a single event repeatedly.

Original Thread

By anonymous    2017-09-20

You'd use Firebase Database queries for that:

DatabaseReference usersRef = FirebaseDatabase.getInstance().ref("users");
Query query = usersRef.orderByChild("contacts/ghopper").equalTo(true);
// My top posts by number of stars
query.addValueEventListener(new ValueEventListener() {
    @Override
    public void onDataChange(DataSnapshot dataSnapshot) {
        for (DataSnapshot snapshot: dataSnapshot.getChildren()) {
            System.out.println(snapshot.getKey());
        }
    }

But this requires that you define an index for each user, which doesn't scale. That is because the structure you have now is meant to allow to easily determine the users for a chat room, and you're trying the opposite.

To efficiently allow getting the chat rooms for a user, you should structure your data so that it also keep a list of users for each chat room. This is often called a secondary/reversed/inverted index.

For more examples of this see:

Original Thread

By anonymous    2017-09-20

Your current database structure allows you to efficiently look up who each user is following. As you've found out it does not allow you to look who a user is follow by. If you also want to allow an efficient lookup of the latter, you should add additional data to your model:

followedByUser: {
  userId2: {
    userId1: true,
  }
  userId10: {
    userId1: true,
  },
  userId223: {
    userId1: true,
  },
  ...
}

This is a quite common pattern in Firebase and other NoSQL databases: you often expand your data model to allow the use-cases that your app needs.

Also see my explanation on modeling many-to-many relations and the AskFirebase video on the same topic.

Original Thread

By anonymous    2017-09-23

This is called many to many relationships, check this out: https://www.youtube.com/watch?v=HjlQH3RsGcU in the middle of the video Frank will say something about it. https://stackoverflow.com/questions/41527058/many-to-many-relationship-in-firebase is maybe something you can use. I think you should denormalise your database to query quicker. Yes you get duplicate data this way.

Original Thread

Popular Videos 698

Submit Your Video

If you have some great dev videos to share, please fill out this form.