Before we get too deep in the hands on implementation of Firebase for Android, lets take a step back for a moment and review what we’ve learned about databases so far.
A database comes into play any time we wish to serve data for our applications in a persistent way.
If you think back to your explorations of Postgres in Java class, you already have experience with one type of Database - namely a SQL database. There are different kinds of SQL databases, with slightly different syntax and capabilities, but they are all structured the same. There are also other kinds of databases that do not run SQL, but are nonetheless relational databases. An umbrella term for these kinds of databases is RDBMS (Relational Database Management Systems). They first came into popularity in the 1970’s, and are therefore very well supported, highly evolved, and very widely used.
As you hopefully remember, SQL stands for Structured Query Language (remember this) and is the language in which we issue commands to our database, either via the command line or through executing our backend code. This example may look familiar:
courses ------- id | name ---+------------------------ 1 | Epicodus 2 | How to cook vegan 3 | Intro to rocket science students -------- id | first_name | last_name |course_id ---+------------+-----------+--------- 1 | libby | brown |1 2 | tiny | tim |1 3 | bub | bles |2 4 | lizzy | cool |1 5 | hank | fresh |3 6 | tiny | tom |1 id | number | type | friend_id ---+------------+------+---------- 1 | 9165551212 | cell | 1 2 | 3235551212 | cell | 2 3 | 4155551212 | cell | 3 4 | 9165552020 | work | 1 5 | 3235552020 | work | 2 6 | 4155552020 | work | 3
SQL databases are fast, well supported and allow us to find, sort and retrieve data easily.
Review the following pseudocode for examples of how SQL can interact with the tables above:
Retrieve all cols of table `students` where `course_id` == course from table `courses` with id = 1; Retrieve all rows of table where `first_name` of student is == ‘tiny’ and `last_name` is == unique; Retrieve `ids` of all students in table `students` in order == ascending;
These are all examples of how SQL allows us to specifically pinpoint data and return it to our code.
SQL databases can be difficult to scale. By nature, RDBMS have to run on a single server in order to maintain database consistency, as the data is basically stored in one giant file. This was not a problem for common data storage needs in the 1970’s, but as data collection needs grew exponentially to where they are today, maintaining the hardware to keep a RDBMS consistent with a guaranteed 99%+ uptime became prohibitively expensive to maintain.
NoSQL databases provide an alternative to RDBMS because they are lightweight, scalable, and can be run much more easily on distributable systems. Next to Firebase, some of the most well known NoSQL databases are Hadoop, MongoDB, Cassandra (used by Facebook) and CouchBase.
NoSQL databases are, by definition, not relational databases and do not store data in a relational way. This literally means that there are no relations between individual parts of the data such as
shoes! Firebase, our NoSQL database of choice, stores data in key-value pairs on the server. Firebase is a cloud services provider that offers realtime databases. Cloud services are simply any resource provided over the internet. Realtime databases are databases that are constantly updating and syncing whenever our data changes. This means we can create a remote database online that will continually sync our data.
NoSQL can easily store the properties of
Objects as key-value pairs. That said, it can be harder to pinpoint specific data, or to pull a dataset that matches a specific set of requirements from a NoSQL database due to its non-relational nature. You can no longer ask the server to provide you a dataset based on how the contents of that set relates to the rest of the data.
Therefore, in your projects, it may be necessary to sort data in the code rather than the database, or to limit which data can be added to the database to avoid data duplicates, as it is not possible to simply ask for "all data where a set of conditions are met but with no duplicates". In general, data redundancy is much less of a concern with non-relational databases as in other areas of our programming - in fact it, it is sometimes necessary in order to link data to other pieces of data. As with planning a SQL database, sketching out a diagram and thinking through your data model before you begin can give you a major advantage.
If all of this is still feeling a little fuzzy - not to worry! You’ll be getting your feet wet very soon, and the pros and cons of SQL vs NoSQL will become very clear.