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

Question

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

Несколько примеров, которые я нашел в Интернете, включая документацию Laravel here и here, похоже, относятся к сценариям миграции, которые обрабатывают только одну таблицу. Я создаю приложение с примерно 10 таблицами, все из которых взаимосвязаны с внешними ключами между ними, а некоторые - с отношениями «многие ко многим».

1. Рекомендуемый подход к использованию одного файла миграции для таблицы? Если да, то почему? (Каковы недостатки размещения всех скриптов создания таблиц в одном файле, если они есть?)

2. Что относительно внешних ключей и отношений? Как принудительно применять эти отношения и порядок, в котором выполняются миграции, так что если таблица1 ссылается на столбец в таблице2, таблица2 создается до таблицы1?

3. Что относительно отношений «многие ко многим»? Нужно ли вручную создавать таблицу отношений (сводная таблица) с помощью отдельного сценария миграции? Если да, то что гарантирует, что он создается после 2 связанных таблиц?

Answer 1

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

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

Внешние ключи являются хорошим примером того, почему вы должны создать одну миграцию за таблицу и даже за внешний ключ: каждый раз, когда вы откатываете таблицу, связанную с внешними ключами, вы должны сначала удалить все внешние зависимости, поэтому 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) Alter миграция

3) php artisan migrate

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

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

2014_07_16_190821_create_statuses_table 

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

CreateStatusesTable 

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