DAVID EAST: [GIBBERISH] JSON [GIBBERISH] Ran out of breath.
SPEAKER 1: Breathing is good.
DAVID EAST: Breathing is really good.
SPEAKER 1: Feel free to breath.
[MUSIC PLAYING]
DAVID EAST: Hey there, everyone.
Welcome to the first ever episode in the Firebase
Database for SQL Developer series.
In this lesson, I'm going to teach you
the differences between how data is stored in SQL databases
and in NoSQL databases, like the Firebase Database.
So, to take a look, let's dive on down to the laptop.
Relational databases use tables to store data,
and a table is made up of columns and rows.
And a column is a field of data, like name, birthday,
or location.
And a row is the entire record that represents that entity.
So, in this case, it would be like a customer,
and honestly, nothing says SQL mode
than a table full of customers.
#SQLJoke
Now, how do we know that each one of these columns
is going to have a valid input?
What happens if we leave one of them blank?
Well, to prevent this, we use schemas.
A schema is like a blueprint.
It defines how the data is organized.
It specifies what the column name is, what the data type is,
and whether it's required.
These specifications are called constraints,
because they constrain some property of the data.
One of the most special constraints
is called the primary key, and each row has one.
And a primary key must be unique because it's
used to uniquely identify each record.
If you want to insert data into this table,
you write an insert statement where
you say what table you want to insert into,
and then also your fields of data,
and then the values of those fields.
Now, let's say I want to add another field like LastName.
What happens if I just go in and add that to my INSERT statement
and, you know, click execute?
Well, it's not going to let me do that.
And that's because LastName isn't already in our schema.
So, if we want to insert LastName,
we need to go and write an ALTER statement
to add it to the schema.
This ALTER statement adds the LastName column,
but it also adds a constraint stating it can't be NULL.
And right now, that's kind of a bit of a catch-22.
Because how can I add the NOT NULL constraint
if there aren't any last names in the table to begin with?
Well, to fix this catch-22, you're
going to have to add the new column without the NOT NULL
constraint and then manually go through your database
and add the last names into each row.
Then after you've done that, you can
come back in and alter the column
to add the NOT NULL constraint.
And then you're finally done.
SQL databases are strict to ensure integrity.
But it can be kind of difficult when you first start out
developing, because you don't exactly
know what your schema is.
And also, you might have a rapidly changing data
structure, so you're constantly altering your schema
and migrating data.
And when you're modeling data relationally,
not everything always just fits.
And this is where NoSQL databases, like the Firebase
database, come into play.
The Firebase database is a NoSQL JSON database,
which is a fancy way of saying it's just a JSON object.
JSON is really simple.
It has keys, and has values.
A key is an identifier, and a value
is, you know, well, it's a value.
Like tables, how do we know what each key
will accept as a value?
Is there a schema that we can use?
Well, the Firebase database, like most NoSQL databases,
are actually schema-less, which means
you don't have to decide what your data structure is up front
to start inserting data.
And this provides you a lot of flexibility,
so you don't have to go back and alter your schema just
to update data.
However, just because you don't have to specify a schema,
it doesn't mean that you can't validate
the types of data that are being saved to the database.
The Firebase database has a rules language
called security rules.
Security rules allow you to specify
the shape and size of data before they
get saved to the database.
These rules can be written after you've
settled on what data structure works best for you,
so it provides you with a lot of flexibility.
You can think of security rules as constraints in SQL.
This example rule checks any direct child keys
underneath the customer's key.
Every time there's a new child saved,
the rule checks to make sure that 'firstName' is a string,
'birthday' is a number, and 'location' is also a string.
And if this expression fails, then the data is not saved.
So, you're still able to validate your data structure
as if it was a schema with constraints.
Insert data, you use the Firebase SDK.
You first grab the database object,
and then you create the reference
to where you want to save the data.
And in this case, we're creating a reference
to the customer's location.
From there, you specify what the child key
is underneath the parent key.
And this child key is like your primary key,
because it's unique within that collection.
And after that, you can just go and save your data.
And this key is unique due to the nature of JSON.
If you try to add another key of "customer_one"
to this data structure, it will just replace the existing one.
So essentially, there is no way to have two "customer_one" keys
underneath the customer's key.
In this example, you can think of customers as a table,
and "customer_one" as your primary key.
But it's not always that cut and dry.
NoSQL databases can be used in this table and row structure,
but you have a lot of flexibility
since you don't have to adhere to a schema.
So, there is sometimes better options
you can use to structure your data.
The main difference between SQL databases and NoSQL databases
is integrity and flexibility.
SQL databases are really inflexible,
but they provide a lot of integrity.
And NoSQL databases are really flexible,
but some of the data integrity is left up
to you, the developer, which you saw with security rules.
So, in the next lesson, I'm going
to take a look at a more advanced relational model
and then convert that to a NoSQL database.
And if you liked this episode, make sure to like and subscribe
so you can stay up to date with all of our content,
like our Firecasts, which are our screencasts.
And if you have any questions for us,
you can send us a question on any social media
of your choice.
Just use the hashtag #AskFirebase,
and we will answer in our weekly Q&A show.
So, that's all for this time.
I will see you in the next episode.
Thanks for watching our video.
You might also want to check out this video or even this one.
I like that one.
And make sure to subscribe.
And now, you can just watch me try
to catch popcorn in my mouth.
Oh!
Two in a row.