All language subtitles for 2.migrations-and-models

Most of the web applications of today need some kind

of permanent database storage.

If you worked with PHP,

you probably used some database management system like

MySQL to store and retrieve data.

And to do that,

you would need to have some kind of a PHP extension such as MySQLi that

allows you to send queries to the running database.

That means that besides programming in PHP,

you would also have to be familiar with constructing raw SQL queries.

In Laravel, we want to avoid doing that.

We want to stay in the domain of PHP and do everything in PHP.

One way in which level Laravel allows us to do that is

by using the so‑called Query Builder.

Query Builder is implemented with this DB façade.

Once you import it,

you can use a chain of methods to construct a query in an object‑oriented way.

So this Query Builder façade will actually write SQL statements, instead of you.

Therefore, all you need to know is how to use these methods.

For example, here, I'm trying to get all of the users from the database.

I specified the users table inside of this table method and

then use get to retrieve all of the records.

This method returns a Collection instance from the Illuminate package,

which kind of works like a regular array.

You can then loop over it and access specific columns from each record by

using the columns name as a property of that object.

And of course, since this is a query builder, your queries can be more complex.

We can use the where method to filter users based on some specific parameter.

You can look up all of the available methods in the documentation,

but we are not going to use DB façade in this course.

There are cases where you would probably want to utilize it,

but I will discuss them later in this lesson.

In this course, I will use Eloquent ORM for managing database resources.

Most of the popular MVC frameworks like Django,

Flask,

or Rails have some kind of implementation of the ORM for database interaction.

ORM stands for object‑relational mapper.

So what is the job of this Eloquent object‑relational mapper.

Its main purpose is to map classes to database tables and the records or

rows from those tables to the instances of that class.

For example, in our application, we are working with the post resource.

To store posts in the database,

we'll probably create a table and name it post, and this table has

some columns like the title and post description.

So in this case,

we can use Eloquent to create a Post class which

will be mapped to this posts table,

and each property of this class will be mapped to one of the table columns.

Once this connection is established,

we can use this mapped class to interact with the table from the database

so that we can work with it in an object‑oriented way.

This will work similarly to the Query Builder façade.

For example,

we can use the all static method to get the

collection of all posts from the database.

This returned collection contains all of the Post

records in the form of objects.

Each object is representing RO from the database so we can use object

properties to get the value of the specific column.

So let's say that I want to get the title of this second post from the database.

I can use find method to get the specific post by ID,

and once I have this post in the form of an object,

I can use the title property to get the title.

As you can see,

this is much simpler than running all kinds of SQL queries and

this abstraction allows us to work with permanent storage just

like with any other object in PHP,

and we usually refer to these ORM classes as models.

So we would call this class the Post model.

Now you have the full picture on why we say that

Laravel follows the MVC architecture.

We use views for presentation, controllers for business logic,

and models for managing resources from the database.

Okay, so now we know how to work with database resources,

but what about the management of the database structure?

What about creating tables or altering the structure of

existing tables in the database? For that purpose,

frameworks like Laravel use migrations.

If you're familiar with GIT version control system,

migrations would be like a versioning tool for your database.

Just like with models,

Laravel provides a way to manage table structure in regular PHP.

Migrations are PHP classes with two required methods, up and down.

Up method defines what the migration should do when we run it.

We can use the schema façade to create tables, and we can define

columns with this blueprint instance of the table.

The down method should do the opposite of up.

So if you ever try to roll back this migration,

the table created in up method should be destroyed.

We define what needs to be done to undo this migration.

So for example, if you work in a team,

every developer can just run these migration files and have the same

structure in its own local development database.

The same can be done for production or testing environment.

So by using these models and migrations,

we can manage the database structure and work with its data

without ever typing a single line of SQL.

Before we try this in practice,

I want to make a quick note about the Query Builder.

If we can use Eloquent models, why does this DB façade even exist?

Even though we will only use models in this course,

there are some situations in which you would want to utilize the DB façade.

If you have some really complex queries and you are concerned

about performance in a more substantial way,

you can consider using the Query Builder because Eloquent

sometimes can have a hit on performance,

but for most applications, models are more than enough.

Also,

if you want to be independent from your models and

work directly with some tables, you can do that with the DB façade.