February 26, 2020
Converting SQL structures to Firebase structures – The Firebase Database For SQL Developers #2

Converting SQL structures to Firebase structures – The Firebase Database For SQL Developers #2

DAVID EAST: Firebase
Database for– oh, OK. All right. Let me just redo this one. Hey, everyone. Welcome to the second episode
in the Firebase Database for SQL Developer Series. In this lesson, I’m going
to take a relational model that you’d see in
a SQL database, and then convert
that to a NoSQL model that works well for
the Firebase database. So let’s dive on
down to the laptop. So this is a
relational model that backs an event
website that allows users to sign up for events. To model this
relationally, we will create a users table, and events
table, and an attendees table. Attendees is a table that
relates users to events. What creates this relation
is called a foreign key. A foreign key is a key in
one table that references a primary key in another table. In this case, the
UID key in attendees is a foreign key
for the users table. And the same goes
for event ID, which is the foreign key
for the events table. If you want to get a list of
attendees for a given event, you would write a SQL
query that looks like this. Here, we’re joining
all three tables to get the relevant data
needed for this query. We’re joining
using foreign keys. Attendees is joined to events
using the event ID key, and users is joined
using the UID key. So how would we model
this in a NoSQL fashion? The Firebase Database is
a NoSQL JSON database, which means that your data
is structured by using JSON. Moving from a
relational model, you might be tempted to do
something like this at first. First, we’d create a users
key, where each child key is a primary key for each user. So one is the primary
key for David, and nine is the
primary key for Alice. Then, we have an
events key, where each child key is a primary
key for each single event. So FM is the event for
the Firebase meet up. Now, for a first try,
this is pretty good. But there is one problem. The attendees key is
embedded within each event. And this is a problem due to the
way the Firebase database loads data. When you retrieve data,
you specify a path. To retrieve a single
event, we would create the path events/FM. Now, the Firebase database will
bring back every single piece of data underneath that
path, which may not be what you want
because you don’t want to download
the attendees just to display a list of events. Rather than embedding
the attendees, we can break them out to their
own root key in the database. Now I’ve created
a new collection called event attendees at
the root of the database. This collection uses the
event ID key and the UID key to represent each user. This makes my data
structure flat, which is a good thing
because it means I don’t have to download my
attendees every single time I download an event. But if I do need
my attendees, I can do that because I’m using of
the same key, which is event ID. And this is how you
would create a Firebase query using the Firebase SDK. First, you will
create two references, one to the events location,
and one to the event attendees location. You’ll notice, too, that
we’re using the same key in each collection. FM is a primary
key for the event, so when used with
event attendees, it’s like a foreign key. Now, to retrieve the
data in real time, I’m going to create a
listener on each reference. And I’m breaking
the listeners out because we can actually render
to the view independently. And this is much easier than
creating an inner listener that acts as a join. A value listener works
best for the single event because value events work
really well when you’re synchronizing objects. And a child listener really
works well for the attendees because attendees is a
list, and child events work well for lists. And just like that, you’ve
gone from SQL to NoSQL with a Firebase Database. And that’s all for today. Tune into the next
lesson, where we’re going to take a look
at common SQL queries, and then convert
them to Firebase queries using Firebase SDK. So that’s all. I was see you all
in the next lesson. Thanks for watching our video. Yeah, we really appreciate it. You should watch
this video, too. And this one. Yeah. And make sure that
you subscribe. It’s really cool.

52 thoughts on “Converting SQL structures to Firebase structures – The Firebase Database For SQL Developers #2

  1. #AskFirebase Assuming that one User has attended many Events, how would I get all the Events one User had attended using the data structure that was shown in the video? Thanks! 🙂

  2. What in cases if user changes his data (username, city, etc)? It means that I need to loop through all json objects and change it?

  3. What if its the case where I have many events and not many attendees. Besides the event being lame, would it be better to opt for having the attendees put along with the events or is it better to have seperate them. Does requesting data from two locations constraint more in this case vs having all the data in one place.

  4. Am I right for an n:n relationships, we will need both EventUsers and UserEvents pathes to enalbe listing entities from both directions?

  5. I can be wrong, but this flexibility come with a maintenance nightmare (replications of data everywhere, need 1 root structure for every join that I need). I can't even think of it working on large team. I think I'm gonna stick with SQL databases and firebase only when I RLY need realtime requirement #RANT

  6. #AskFirebase as a browserify fan, it there any way of using firebase with npm/browserify? Tried to implement it, but got errors "firebase not found" until i put firebase script src to html file and then it was working. Thanks!

  7. #AskFirebase Does the server upload transfer data to realtime database counting in price? The price table describes GB downloaded. I do not understand the standard. Thanks!

  8. Another question how to work with information that get updated after they have been put in a relation.
    My application lists places. The details for each place can be updated any time. The users of my database can mark their favorites places. The ids for the places are stored in the user table as an object.
    – With an SQLdatabase, I would create a query to just select the place details for the stored IDs of favorites and get the data. Can I do something similar with Firebase?
    – Or should I store all details of a favorite place in the user database and update every instance of the place at every user when the details of the place are updated (it does not even feel right to ask the question)?

    Background: working with javascript and Polymer/polymerfire

  9. My main problem with this is i want to build an app with a very large collection of static data that is inherently and inexorably relational. The answer to "how do you have a foreign key in firebase" seems to be that, really, you just can't. The data will not resolve itself and you have to basically use naming conventions to simulate a foreign key. In a relational database foreign keys can be validated and ensured by the system itself, forbidding the insertion of an illegal key. In firebase it seems like one typo in a large dataset seems to mean you're going to be hunting for an awfully long time about what is spelled wrong. At least in MongoDB you can use the "$ref":{} notation. It's ugly and a pain, but it works.

    Imagine, for a sample example, you were making a game and wanted the server to generate Diablo style dropped weapons. Diablo has a massive list of weapons, with foreign relations to the handedness of the weapon, a range of whitelisted properties it can have applied to it, unique abilities, associated pre and posftxes for the names depending on those abilities, number of properties that can be applied based on the rarity of the weapon, and it goes on and on.

    This is a complicated set of inherently relational data, and I wish there was a better way to have these realations strictly enforced for their legality. I'm not saying a NoSQL database cannot represent this data, but I am saying I feel a relational database will represent it more cleanly and make it easier to work with. Relational DBs aren't always the way to go, but sometimes there's an awful lot of value in those relations.

  10. Pause at 2:16. Isn't that stupid? The names 'David' and 'Alice' are redundant. There should rather be a single JSON array with the ids of all attendees.

  11. this was very helpful but can u do something like this for android i am haven't lots of trouble querying and the moment

  12. Great video! Just a minor correction – The alias for Events table should be "e" instead of "event" in the query example at 1:15.

  13. Does Bob know Alice is meeting up with David? (2:09) Joking aside, thanks for the video it's very helpful.

  14. in sql we put all name in table and make a relationship between it and users table
    Name { NameID (int),Name (string) } Users {UserID (int) , FirstName (int) ,secoundname (int)  }

    how to make this in Firebase???

  15. Okay so I think if you want to use user ID's in the eventsAttendees it should look something like this.

          "fm": {
                  "0" : "1",
                   "1": :9"

    If someone could tell me if this is the correct way to do this and best practice that would be great 🙂

  16. #AskFirebase
    So every client will download a full list of UID's with names? Was this video really described as a advanced example ?

  17. #AskFirebase What if I have lots of events and I realize that the name of one of the attendees is wrong who is in many of the events, is there a way to update all at once?, I see this as main con on noSQL, how do you manage it?

  18. Ok, I got it. This video explains, how to implement 'many-to-many' in firebase for SQL-developers, but how to do it right for no-sql developers? Should events contains attendees with users-data, or maybe just store array with uid's? In MongoDB documentation said, that if document should contains few subdocuments, we can just store their in array, but if there gonna be many subdocuments, is better to store id's of subdocuments in array. How about Firebase? Can I do it like in MongoDB, or there is another rules?

  19. Late at the party; funny no-one noticed before that the SQL query at 1:11 won't work, as "e" and "u" are referenced, but never defined.
    Though I think all humans still understand what was meant. And what is === in SQL?

  20. Hii sir, Answer my query

Leave a Reply

Your email address will not be published. Required fields are marked *