Understanding Laravel migrations with PostgreSQL - php

Question

I'm learning laravel 5 and it's relationship with databases. I can find tons of info regarding how to work with sqlite and mysql but I'm having problems understanding what migrations are, how they are related with databases and my main issue...
If I have a pre-created postgres database with, let's say, 10 tables and their relationships already up and running, how can I make Laravel interact with them?
For example, I have my postgres schema table defined like this:
CREATE TABLE "users" (
"id" integer NOT NULL DEFAULT nextval('users_seq'),
"name" character varying(30) NOT NULL,
"email" character varying(50) NOT NULL UNIQUE,
"password" character varying(120) NOT NULL UNIQUE,
CONSTRAINT users_pk PRIMARY KEY ("id")
) WITH (
OIDS=FALSE
);
I already know Laravel comes with a generic migration for users table but how exactly should I work from within Laravel connecting to my db?
By the way, my database's name would be dummy.
May I use something like a migration class?
But as far as I understand, migrations are for creating/deleting/etc tables, right?
Or should I directly create a controller to interact with de db like these?
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use App\Http\Requests;
class PagesController extends Controller
{
public function index()
{
$users = DB::table('users')->get();
return view('DBHandler',compact('users'));
}
}
And I imagine this is the query builder way of doing things and eloquent's way is quite different.
Any help would be appreciated.

Answer 1

According to Documentation of Laravel:
Migrations are like version control for your database, allowing a team to easily modify and share the application's database schema. Migrations are typically paired with Laravel's schema builder to easily build your application's database schema.
If you have a team working with you, is highly recommendable to use them for changes that must be applied on the scheme to the application works, these migrations let you to apply changes to database like drop, create, update, etc. On the other hand if you're going to start developing with a Schema already created, there is no problem you can interact with your scheme with Eloquent.
The way as Laravel take information from your database is with Eloquent a ORM, Here is the introduction from Laravel Documentation:
The Eloquent ORM included with Laravel provides a beautiful, simple ActiveRecord implementation for working with your database. Each database table has a corresponding "Model" which is used to interact with that table. Models allow you to query for data in your tables, as well as insert new records into the table.
So you have to create a Model for each one of your tables, except tables many to many. If your table is Users you must name the model User and Eloquent take it automatically if not, you must overwrite the $table attribute at the model like this:
public $table = 'user';
The rest what you can do with Eloquent you can find it at the documentation here
I hope this helps you out.

Answer 2

From the blog laravelbooks.com, quoting:
[...] Migrations are the Laravel way of helping you to evolve the database schema of your application (also known as its DDL) without having to drop and re-create the database each time you make a change. And not having to drop and recreate the database each time a change happens means that you don’t lose your development data. The only changes made when you execute a migration are those necessary to move the schema from one version to another, whether that move is forward or backward in time.
Not only does Laravel migration provide you with a means to change your database schema in an iterative manner, but it lets you do so using PHP code, rather than SQL! The Laravel Schema Builder allows us to create database tables and insert columns or indices quickly. It uses clean and expressive syntax to make database operations happen. You may think of Laravel migration as version control for your databases! [...]
There I found a more explanatory way to laravel than the official documentation, though the later it's also good