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.
