DAVID EAST: Eh. OK. Eh. Let's light it on fire
and send it to the world. All right. Let's do this. [MUSIC PLAYING] Hey, everyone. Welcome to the sixth lesson
in the Firebase Database for SQL Developer series. And today, we're talking
about denormalization. And if you're coming from ASQL
background, which you probably are, since you're watching
this, you probably know a lot about
normalization, which is reducing data duplication
at all costs in your database. And normalization is great. But today I want you
to take that idea, that concept--
take it right here and just put it right down here. Don't lose it though, because
it's really important. But I want you to
have an open mind when we talk about denormalization,
because it's pretty much going to contradict
everything that you know about normalization. So to learn more, let's dive
right down into the laptop. Denormalization is just
simply duplicating data. And to be more specific,
it's duplicating data to simplify or reduce querying. This database model
is what we've been using for the entire course. It is our events database. And we have users, events,
and event attendees. So event attendees is
sort of a junction spot for events and users,
so we know which users are going to which events. And we can see that
through sharing the key of FM for the
events for Firebase Meetup, and also the one in
nine keys, which are the user IDs underneath users. And obviously, you'd be
using a push ID or a Firebase authentication ID. But this is just
to keep it simple. And underneath event attendees,
we're storing just the name. So if we wanted to get the
entire results for the user, we had to do a
join, which is what we did in the previous video. And the way this join looked
was that we grabbed a route reference from the database. And then from there,
we grabbed a reference to eventattendees/fm, and
that's the Firebase Meetup. And then attached a
child event listener, which fired off for every
attendee at the event. When each attendee
went and fired off, we went and grabbed a
reference to their data underneath users, using the key. And then called once
and got that data back, and so effectively
joining the two together. Now, this is fine if you're
not doing this query that often or if it's a small set of data. But once your access
pattern grows larger and you're running
this query all the time or you're running this
on a larger data set, you'd probably like to
eliminate this inner read and just read this data
one time just like this-- just with a simple child added. But currently we
can't, because you can see underneath
event attendees, we're just storing the name. But what if, rather
than storing the name, we stored the
entire user object? And this way we could just do
that one read and we'd get back everything we needed about
the users just by saying child added on eventattendees/fm. So a big question
I always get is, when do I denormalize my data? How do I know to duplicate
data here or there? And the rule of thumb
is you want to structure your data after your view. So I built this app
called Bonfires, which is a list of Firebase events. And Bonfires uses the
same events database that we're using in this series. And which you can see up
here at the top in Bonfires is that there is a
navigation bar, where we can click Featured, SF,
Denver, London, and Berlin. And it will bring us back
those specific events at those locations. Now, you would imagine
that something you could do is you could just say, I'm going
to do a query on the events key. And I'm going to say order
by child location equal to SF or equal to Denver. But rather than do that,
I could also denormalize. So I could create a
completely new data structure called locationevents,
and then from there key off each location-- so
SF for San Francisco and BER for Berlin-- and then store
each event at that location underneath that location key. And then if you just
need to read the data, it's just a straight read. There's no querying. You just create a reference
to locationevents/SF, and then attach a real-time listener. And that's all you need to do. And then if you need to
do this for another city, you just change the key. So instead of San
Francisco in this case, we choose Berlin and
attach our listener. And the great
thing about this is that if you need to
do further querying, nothing's stopping you. You still have the
ability to order by any child within
the locationevents key. So another big question
about denormalization is, what about the
consistency of my data? So if you're duplicating
data all over the place, how can you ensure that
when it changes in one spot it changes everywhere? So take a look at
our users database. We have users and we
have event attendees. And in users, if the user David
goes and changes their name to Dave, you can see that
it won't automatically go and propagate
to event attendees. And so this could be
a bit of a problem, because you don't
have the consistency that you're looking for. Denormalization is just
simply duplicating data to simplify or reduce querying. And once you start
duplicating your data throughout your
database, it becomes really simple to read
your data, because you don't have to do a
complex join or a query. But the problem is
with consistency-- is when you start
duplicating data everywhere, it becomes hard to make
sure it's all consistent. And you can fix that
with multi-path updates, which we will be covering
in the next lesson. So if you like this video, make
sure to like and subscribe. And I will see you all
in the next lesson. [MUSIC PLAYING] Hey, thanks for
watching our video. You might also enjoy this
video, or even this video. And you should subscribe,
because it's a snap! [SLAPPING] [MUSIC PLAYING] Ow! Ow. That was a bad decision.
