... JSON ... I lost my breath. "Breathing is good. - It's very good. You can breathe. Database Firebase for SQL Developers 1 - SQL Databases and the Firebase Database Hello, everyone. Welcome to the first episode of the Firebase Database series for SQL developers. In this lesson, I'm going to teach you the difference between how data is saved in a SQL database and in a NoSQL database, such as Firebase Database.
To start, let's go to the laptop. Relational databases use tables to save data and a table is made up of columns and rows. A column is a field that can contain something like "name," "birthday," or "place." And a line is everything that represents that entity. In this case, it could be a customer. And, honestly, nothing sounds as SQL as a multi-client table. #SQLJoke How will we know that each of these columns will have a valid entry? What happens if any goes blank? To avoid this, we use "Schemas". A Scheme is like a diagram. Defines how the data will be organized. It specifies the name of the column, the data type, and whether it is required.
These specifications are called "Restrictions" because they restrict some properties of the data. One of the most notable Restrictions is called the "primary key" and each row has one. A primary key must be unique because it is used to identify each data entry. If you want to enter data in this table, enter an INSERT statement that indicates which table will receive the data, which fields will be filled, and the values for such fields. Let's say I want to add a field that I'll call LastName. What happens if I add it to the INSERT statement and click execute? He will not give me permission to do that.
Because "LastName" is not yet in our Schema. So if we want to insert "LastName", we need to go back and insert an ALTER statement to add it to the Scheme. The ALTER statement creates the "LastName" column, but also adds a constraint because it can not be NULL. And this becomes a paradox. So how do I add the NOT NULL constraint if there is no value in the table for "LastName"? To fix this paradox, you will have to add a new column without the NOT NULL constraint and then manually enter the values in each row.
Once you have done this, you can change the column to add the NOT NULL constraint. After that, the table is ready. SQL databases are rigid to ensure greater data integrity. But it can be tricky when you start to develop because you do not know how your Scheme will work. And there may be sudden changes in the data structure, which will force you to change your Scheme and migrate the data.
In relational models, everything does not always fit. And this is where NoSQL, like the Firebase database, comes into the picture. Firebase Database is a JSON database in NoSQL. It's a fancy way of saying it's just a JSON object. JSON is very simple. It has keys and values. A key is an identifier and a value is ... a value. Just like in the tables, how do you know what each key will accept as value? Is there a Schema that we can use? Well, Firebase Database, like many NoSQL databases, does not have Schemas, which means you do not have to define the structure of your data before you insert them. This provides flexibility because you do not need to change the Schema just to update data. However, just because you do not need to specify a Schema, this does not prevent you from validating the types of data that will be saved to your database.
The Firebase Database has a rule language called "Security Rules". Security Rules allow you to specify the shape and size of the data before it is saved to the database. These rules can be specified after you have decided the best structure for your data, giving you more flexibility. You consider the Security Rules as the SQL Restrictions. This rule example checks all direct child keys below the client key. Every time a new child key is saved, the rule confirms that "firstName" has the form String, "birthday" has Number, and "location" also has String format. If the parameters are different, the data will not be saved. You will still be able to validate your data structure as if there is a Constraint Scheme. To create the data, you can use the Firebase SDK. We choose an object from the database to create a reference where the data will be saved.
In this case, we have created a reference to the client location. Then specify the role of the child key under the parent key. This child key will be like your primary key, because it will be unique in that collection. After that, you can save your data. And the key is unique because of the nature of JSON. If you try to add another "customer_one" key to this data structure, it replaces the previous one. Essentially, there is no way to have two "customer_one" keys under the "clients" key. In this example, you can imagine clients as a table and "customer_one" as the primary key. But the procedure will not always be so straightforward. NoSQL databases can be used in the structure of columns and rows, but you have flexibility since you do not need to adhere to a Schema. Sometimes there are better options for structuring your data. The main difference between SQL databases and NoSQL lies in data integrity and flexibility. SQL databases are very inflexible, but give us much more data integrity.
NoSQL databases are fairly flexible, but part of the data integrity depends on the developer, as you saw with the Security Rules. In the next lesson, we'll explore a more advanced relational model that will be converted to a NoSQL database. If you liked this episode, do not forget to enjoy and sign up to stay up to date on our content, like our Firecasts series that features several tutorials. And if you have any question for us, you can send it through any social network of your choice. Just use the #AskFirebase hashtag. We will respond in the weekly Q & A program. And that is all. See you in the next episode. Thanks for watching the video. You might also like this one or this one. I like this. And sign up. Now, feel free to see me try to get popcorn with your mouth.
Two in a row! .
