app/migrations/create_user.php
public function up(){
Schema::create('interns', function($intern){
$intern->increments('id');
$intern->string('name');
$intern->integer('salary');
});
}
So the above function creates a table called "intern" but along with that it also creates a "migrations" table on running the command "php artisan migrate". Why is it doing this?
It's Laravel's way of keeping track of which migrations have been run.
Let's assume you make another table but it doesn't work right, so you need to run php artisan migrate:rollback. Laravel will know that the second table was created in the second batch and only rollback that one, leaving your interns table alone.
Every time you run another migration, that table will be updated with the migration's file name and the batch it was ran in.
The migrations table is for laravel to track the version the database is running.
For each migration it'll insert a new row into the migrations table, so that when you run migrate:rollback it knows what migrations to undo, and likewise, it knows what migrations to run going forward.
If you look at the migrations table you'll see it keeps a record of the migration name and batch number. The batch number is a sequential order that the migrations are run in. For example, you might create a users table. You run that and laravel logs the filename and batch number. Next you might add an accounts table that the users table is associated to. For this you would create 2 new migrations, one to create the new accounts table the other to edit the users table to add a new column account_id. Next time you migrate, both of the new migrations will be run, but assigned under the same batch id.