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.