Laravel несколько таблиц за миграцию

Во время разработки вашего приложения я не думаю, что вам следует слишком беспокоиться о том, чтобы иметь только одну таблицу на миграцию, иногда просто проще объединить несколько таблиц в одной миграции, но как только ваша система перейдет в производство, вы не сможете продолжать так работать, потому что вы будете мигрировать только в производстве и, вероятно, никогда не откатитесь, поэтому ваши миграции будут действительно небольшими, иногда у вас будет миграция для создания одного столбца.

В преимущества размещения таблиц в разных миграциях аналогичны наличию тонкого класса: чем меньше информации у вас в одном файле, тем проще управлять им и вносить в него изменения. Поэтому, если вы поместите все таблицы в одну миграцию, ее будет сложнее поддерживать, но это действительно зависит от вас.

Внешние ключи являются хорошим примером того, почему вы должны создавать одну миграцию для каждой таблицы и даже для каждого внешнего ключа: каждый раз, когда вы откатываете таблицу, связанную с внешними ключами, вы должны сначала удалить все внешние ключи. зависимости, вот почему Laravel создает и переносит их все в одном порядке, это помогает вам никогда не испортить удаление таблицы. Итак, сначала создайте миграции таблиц, затем создайте миграции внешних ключей, поэтому при откате сначала будут отменены ограничения, а затем таблицы.

Я создаю внешние ключи для таблицы в той же миграции этой таблицы, если у меня не слишком много перекрестных внешних ключей. Но я всегда создаю внешний ключ в отдельной команде Schema::table(), потому что некоторые базы данных вам нужно, чтобы у вас был столбец, прежде чем прикреплять к нему ограничение:

public function up()
{
    Schema::create('statuses', function(Blueprint $table)
    {
        $table->string('id', 64)->primary();

        $table->string('user_id', 64)->index();
        $table->text('body');

        $table->timestamps();
    });

    Schema::table('statuses', function(Blueprint $table)
    {
        $table->foreign('user_id')
                ->references('id')
                ->on('users')
                ->onUpdate('cascade')
                ->onDelete('cascade');
    });
}

О многих ко многим, если вы создаете таблицу и внешние ключи вместе, вам следует сначала создать главную, а затем сводные таблицы, но если вы создаете свои внешние ключи в отдельных миграциях, сначала создайте таблицы (порядок не будет иметь большого значения, но в этих случаях также лучше организовать), а затем миграции для внешних ключей.

Во время разработки я делаю много изменений в своем таблицы, поэтому я всегда возвращаюсь к ним, поэтому вот что я делаю, когда изменяю миграцию:

1) php artisan migrate:reset много раз

2) Изменить миграцию

3) php artisan migrate

Если я просто создаю новый, обычно у меня не будет никаких проблем, потому что миграции обычно являются идепотентными.

На ваш последний вопрос уже был дан ответ, но я повторю еще раз: Laravel называет файлы миграции с использованием меток времени, так как у вас никогда не будет миграции, выполняемой раньше другой тот, который был создан до этого:

2014_07_16_190821_create_statuses_table

И имя миграции имеет значение, потому что это выше создаст этот класс:

CreateStatusesTable

Итак, одна вещь, которую вы должны сделать, это создать каждую миграцию с другим именем, иначе вы получите два класса с одинаковым именем, и не Laravel, а PHP будет жаловаться на это.