Databases
There are many types of databases. Each database type is designed and optimized for a certain purpose and data type. Rails works with many different types of databases. The most popular databases is relational databases. It essentially works like an Excel spreadsheet, but with more advanced extendible features.
Let's look at the following example, where we have a list of books with attributes of name, author name and publication year
A relational database is designed to store structured data similar to the one shown above. Each column is an attribute, and each row is a different data entry to the table. Now, what if we want to make each entry contain more data? We can just add more attributes / columns to contain more information on each row. Below, we added each author's country of origin and birth year.
Take a look at the table above. What characteristics do you see?
One thing we see is that there are some duplicated information. The author's name, location and birth year have been repeated several times, making them redundant. As a software developer, it smells like we can do some normalization.
Normalization is a systematic approach of decomposing tables to eliminate data redundancy.
Here, what we should do is to split this single table into 2 different tables: Author and Book. Each author will have a unique identifier (ID), so we can relate each book to its author through identifiers.
Let's see how this will look like.
As you can see, by having two tables, we no longer see data redundancy. We also don't lose any information through this process. Essentially, we can store the same amount of information with less space. This practice is called normalization, and it's the core basis of relational databases.
Database Schema
To specify how you want your table to look, how many tables you want, what attributes to include in your tables, you have to define them somewhere. You also want to be able to modify these table structures from time to time as things change.
The piece of artifact defining the structure of your tables is called database schema.
You can't directly edit the database schema like a Word document. Instead, each revision to the database schema requires a schema migration. Schema migration is the management of incremental, reversible changes to relational database schemas. Another key word is reversible. Reversibility allows you to to roll back / reverse a migration if necessary.
Schema Migrations
In any MVC frameworks, like Rails, there will be a system to help you modify database schema through schema migrations.
ORM (Object-relational Mapping)
In relational databases, we use SQL (Structured Query Language) to add / delete / modify records.
For instance,
INSERT INTO AUTHORS (ID,NAME,LOCATION,BIRTH_YEAR)
VALUES (1, 'J. K. Rowling', 'United Kingdom', '1965');
We are adding an author (J. K. Rowling) into our table AUTHORS.
INSERT INTO AUTHORSmeans to "add the following record to the Authors table"(ID,NAME,LOCATION,BIRTH_YEAR)defines the attributes(1, 'J. K. Rowling', 'United Kingdom', '1965')defines the attributes1corresponds to ID'J. K. Rowling'corresponds to NAME'United Kingdom'corresponds to LOCATION'1965'corresponds to BIRTH_YEAR
We use SQL to add, update, retrieve and delete records. There are simple and advanced operations in which you can do.
Now, a lot of MVC frameworks recognize that SQL is not a friendly language to use in general practice. You should be able to achieve the same SQL tasks by using, say, Ruby or JavaScript.
For example, it would look a lot better, if we can do
Author.create(name: 'J. K. Rowling', location: 'UK', birth_year: '1965')
Now, this is a lot more human readable. We know that we are creating a new record for the Author table.
MVC frameworks like Rails apply a method called ORM (Object-relational Mapping), so that you can interact with the database using the primary language of the framework.
In the case of Rails, you can run all database operations by writing Ruby, rather than SQL, powered by Rail's Object-relational Mapping.