Afrikaans
Akan
Albanian
Amharic
Armenian
Azerbaijani
Basque
Belarusian
Bemba
Bengali
Bihari
Bosnian
Breton
Bulgarian
Cambodian
Catalan
Cebuano
Cherokee
Chichewa
Chinese (Simplified)
Chinese (Traditional)
Corsican
Croatian
Czech
Danish
Dutch
English
Esperanto
Estonian
Ewe
Faroese
Filipino
Finnish
French
Frisian
Ga
Galician
Georgian
German
Greek
Guarani
Gujarati
Haitian Creole
Hausa
Hawaiian
Hebrew
Hindi
Hmong
Hungarian
Icelandic
Igbo
Indonesian
Interlingua
Irish
Italian
Japanese
Javanese
Kannada
Kazakh
Kinyarwanda
Kirundi
Kongo
Korean
Krio (Sierra Leone)
Kurdish
Kurdish (Soranî)
Kyrgyz
Laothian
Latin
Latvian
Lingala
Lithuanian
Lozi
Luganda
Luo
Luxembourgish
Macedonian
Malagasy
Malay
Malayalam
Maltese
Maori
Marathi
Mauritian Creole
Moldavian
Mongolian
Myanmar (Burmese)
Montenegrin
Nepali
Nigerian Pidgin
Northern Sotho
Norwegian
Norwegian (Nynorsk)
Occitan
Oriya
Oromo
Pashto
Persian
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Punjabi
Quechua
Romanian
Romansh
Runyakitara
Russian
Samoan
Scots Gaelic
Serbian
Serbo-Croatian
Sesotho
Setswana
Seychellois Creole
Shona
Sindhi
Sinhalese
Slovak
Slovenian
Somali
Spanish
Spanish (Latin American)
Sundanese
Swahili
Swedish
Tajik
Tamil
Tatar
Telugu
Thai
Tigrinya
Tonga
Tshiluba
Tumbuka
Turkish
Turkmen
Twi
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Welsh
Wolof
Xhosa
Yiddish
Yoruba
Zulu
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.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.