What else would you want on a typical pivot table...say for posts and tags.

migration.php

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;

class PivotPostTagTable extends Migration {

    /**
	 * Run the migrations.
	 *
	 * @return void
	 */
	public function up()
	{
		Schema::create('post_tag', function(Blueprint $table) {
			$table->integer('post_id')->unsigned()->index();
			$table->integer('tag_id')->unsigned()->index();
			$table->foreign('post_id')->references('id')->on('post')->onDelete('cascade');
			$table->foreign('tag_id')->references('id')->on('tag')->onDelete('cascade');
		});
	}



	/**
	 * Reverse the migrations.
	 *
	 * @return void
	 */
	public function down()
	{
		Schema::drop('post_tag');
	}

}

This will go in the new generate:pivot helper command. So the above will be dynamically generated when you run:

php artisan generate:pivot posts tags

What about the alphabetical order of the tables name?

Yeah, that's already been added.

1. An id auto increment will give better performance on high load.
2. Indexes on all the fields. (Fixed)

+1 Yeah, the recomendation is have an id on all your table, even the pivot tables, and what about the timestamps ?

#2 is fixed. Just forgot to add that.

I wasn't sure what the rule was on adding an auto-increment id to joinables. But I can add it easily if that's a good rule to follow.

Okay, so now, when you run:

php artisan generate:pivot tags posts

...it'll generate the following migration:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;

class PivotPostTagTable extends Migration {

    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('post_tag', function(Blueprint $table) {
            $table->increments('id');
            $table->integer('post_id')->unsigned()->index();
            $table->integer('tag_id')->unsigned()->index();
            $table->foreign('post_id')->references('id')->on('post')->onDelete('cascade');
            $table->foreign('tag_id')->references('id')->on('tag')->onDelete('cascade');
        });
    }



    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('post_tag');
    }

}

@montogeek timestamps it's more an user preference I think. I usually add it. I suggested @JeffreyWay that it could be an option.

That's is because I suggested it, I use to add it too, will be great has option! :)

I think I'm going to leave timestamps off for the time being. Takes two seconds to add it manually.

I know you said you were going to leave it off, but just for reference, I +1 the addition of timestamps

Could you make the foreign key constraints optional (default on is fine).