Laravel每个迁移有多个表 [英] Laravel multiple tables per migration

问题描述

我是Laravel的新手，所以对这个框架的最佳做法有些陌生.我正在尝试理解使用迁移的最佳方法.

I am new to Laravel, so a bit new to this framework's best practices. I am trying to understand the best way to approach creating a database using migrations.

我在网上找到的一些示例，包括Laravel文档此处和此处，似乎是指仅处理一个表的迁移脚本.我正在创建一个约有10个表的应用程序，所有表都与它们之间的外键相互关联，其中有些表具有多对多关系.

The few examples I found on the web, including the Laravel documentation here and here, seem to refer to migration scripts that handle only one table. I am creating an application with around 10 tables, all interrelated with foreign keys between them, some with many-to-many relationships.

1. 是否建议每个表使用一个迁移文件?如果可以，为什么? (将所有表创建脚本放在一个文件中(如果有)的缺点是什么?)

1. Is the recommended approach to have one migration file per table? If so why? (What are the disadvantages of putting all table creation scripts in one file, if any?)

外键和关系如何?

多对多关系如何?关系(数据透视)表是否也需要通过单独的迁移脚本手动创建?如果是，那么如何确保在2个相关表之后创建它?

What about many-to-many relationships? Does the relationship (pivot) table need to be created manually too through a separate migration script? If yes what ensures that it is created after the 2 related tables?

推荐答案

在应用程序的开发过程中，我认为您不应该太在意每次迁移只有一个表的情况，有时在一个表中包含一些表togheter会更容易一次迁移，但是一旦您的系统投入生产，您将无法继续工作，因为您将仅在生产中迁移并且可能永远不会回滚，因此您的迁移量将非常小，有时您会迁移以创建单个列.

During development of your application I don't think you should care too much having only one table per migration, sometimes it's just easier to have some tables togheter in a single migration, but as soon as your system go to production, you will not be able to keep working like that, because you will only migrate in production and probably never rollback, so your migrations will be really small, sometimes you'll have a migration for a single column creation.

将表放在不同的迁移中的优点与拥有一个瘦的类相同，在一个文件中拥有的信息越少，就越容易管理和更改它.因此，如果将所有表都放在一个迁移中，则维护起来会更加困难，但这实际上取决于您.

The advantages of putting tables in different migrations is the same of having a thin class, the less information you have in one file, the easier is to manage and make changes on it. So if you put all tables in a single migration, it gets harder to maintain, but that's really up to you.

外键是一个很好的示例，说明为什么应该为每个表甚至每个外键创建一个迁移:每次回滚与外键相关的表时，必须首先删除所有外依赖，这就是Laravel创建迁移它们的原因所有这些都以相同的顺序进行，它可以帮助您永不浪费桌子的下落.因此，首先创建表迁移，然后再创建外键迁移，所以回滚时将先回滚约束，然后再回滚表.

Foreign keys are a good example of why you should create one migration per table and even per foreign key: every time you rollback a table related to foreign keys, you must first delete all foreign dependencies, that's why Laravel creates a migrates them all in the same order, it helps you never screw a table drop. So, create your tables migrations first, then you create your foreign keys migrations, so when you rollback it will first rollback the constraints and then the tables.

除非表中的交叉外键太多，否则我会在该表的同一迁移中为该表创建外键.但是我总是在单独的Schema::table()命令中创建一个外键，因为某些数据库需要在将约束附加到该列之前先拥有该列:

I create foreign keys for a table in the same migration of that table, unless I have too much cross foreign keys. But I always create a foreign key in a separate Schema::table() command, because some databases need you to have the column before attaching the constraint to it:

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');
    });
}

大约很多，如果创建表和外键切换器，则应首先创建主表，然后再创建数据透视表，但是如果要在单独的迁移中创建外键，则首先创建表(顺序不会很重要，但是在这种情况下最好进行组织)，然后再进行外键的迁移.

About many to many, if you create the table and foreign keys togheter, you should first create the master and then the pivot tables, but if you are creating your foreign keys in separate migrations, first create the tables (order will not matter much, but it's also better to be organized in those cases) and then the migrations for the foreign keys.

在开发过程中，我在表中进行了很多更改，因此我总是回到表上，因此这是我在更改迁移时要做的事情:

During development I do a lot of changes in my tables, so I'm always coming back to them, so this is what I use to do, when I'm altering a migration:

1)php artisan migrate:reset多次

2)更改迁移

3)php artisan migrate

如果我只是创建一个新的，则通常不会有任何问题，因为迁移通常是幂等的.

If I'm just creating a new one, usually I won't have any problems, because migrations are usually idepotent.

您的最后一个问题已经得到回答，但是我会再说一遍:Laravel使用时间戳命名迁移文件，这样您就永远不会在之前创建另一个迁移之前就进行迁移:

Your last question was already answered, but I'll say it again: Laravel name the migrations files using timestamps, the way you will never have a migration being ran before another one created before it:

2014_07_16_190821_create_statuses_table

迁移名称，因为上面的内容将创建此类:

And the name of the migration matter, because this one above will create this class:

CreateStatusesTable

因此，您必须做的一件事就是用不同的名称创建每个迁移，否则，您将得到两个具有相同名称的类，而不是Laravel，但是PHP会抱怨它.

So one thing you must do is to create every migration with a different name, otherwise you will end up with two classes with the same name and, not Laravel, but PHP will complaint about it.

这篇关于Laravel每个迁移有多个表的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！