引言

书接上回。我们讲完了路由，又顺带讲了中间件；接着又讲了控制器，还把路由的数据发到控制器，并且渲染到视图页面。更深入的是，把视图文件的模板也说明白了。

MVC - CVM - VMC，到底缺了哪一个呢？M！

M = Model，是模型层，是与数据库直接对接的那一层设计。我们都知道一切应用的基础，是数据库。数据库也是IT工业的珠穆朗玛峰，看当今天下，多少大中小微企业，哪个不是被数据库卡着脖子。

所以美国要是哪天让Oracle，Microsoft等公司限制出口数据库产品，我们国内的数据库能不能顶上，还未可知。

好了，扯得有点远了，说说本期的要点吧。 我们本期要使用laravel自带的迁移功能，在不操作任何数据库的条件下，完成基础的数据构建。

迁移文件

本文假设你已经正确地配置了环境变量文件，并且通过数据库配置项，系统已经可以正常连接到数据库了。 在项目文件里，不出意外你会在目录 database/migrations 下发现 2014_10_12_000000_create_users_table.php 文件， 这个是laravel自带的用于创建 users 表的迁移文件。只要是实现了两个方法，一个是 up 用于执行命令，一个是 down 用于回滚操作。

来看一下初始的内容，首先是 up 方法：

public function up()
{
    Schema::create('users', function (Blueprint $table) {
        $table->increments('id');
        $table->string('name');
        $table->string('email')->unique();
        $table->string('password', 60);
        $table->rememberToken();
        $table->timestamps();
    });
}

我们主要关心的是字段的数据类型，以及默认值约束，唯一性约束等等。而字段类型也做的很直观，string 对应 varchar 类型。 比如主键默认的自增 id，还有用于记录创建时间 created_at 和 更新时间 updated_at，一个 timestamps() 方法就包含了， 只不过默认使用的是不直观的整型时间戳，如果要使用 datetime 格式用于直观地读取，则可以手动声明：

$table->dateTime('created_at')->comment('创建时间');
$table->dateTime('updated_at')->comment('更新时间');

与创建表方法对应的是回滚时候的删除表，下面是默认的 down 方法：

public function down()
{
    Schema::drop('users');
}

其实这个写法有点不保险，如果 users 表不存在的话，我们并不需要执行这条命令。所以，可以完善性地添加一个存在条件判断：

Schema::dropIfExists('users');

这样生成的就是类似下面的额 SQL 语句：

DROP TABLE IF EXISTS databse_name.users;

迁移文件准备完毕，要将该功能应用起来，只需在命令行输入：

php artisan migrate

系统就会执行迁移文件内的内容，并组装好SQL语句发送给数据库执行。

自力更生

那么，上面的是系统自带的迁移文件，开发者如何自己手动生成呢？其实laravel提供了齐备的命令行脚手架， 下面的方法都可以用于创建一个迁移文件：

php artisan make:migration create_users_table
php artisan make:migration add_votes_to_users_table --table=users
php artisan make:migration create_users_table --create=users

第一个仅仅指定了迁移文件名称，一般我们给它起一个直观的名字，方便给自己和维护者提个醒 :-)

第二个使用了 --table 选项指定该迁移文件是对哪个表起作用的。

第三个使用了 --create 选项，这样不仅创建了迁移文件，还顺带着把模型给建好了，一石二鸟！

创建新表没啥好说的，字段类型一定要选好，如果写好了，又进行了迁移，数据库也生效了，这时候，半路上要修改字段类型， 最好数据库里没数据，要是有，可就要遭殃，比如说原本是 varchar(50)，有的字段写满了50个字符，现在要修改为 varchar(20)， 数据库是不允许的。

可以向上扩展，向下，对不起，数据库说 NO！怎么办？只能手动处理数据到合适的长度再做修改。

而在 laravel 里对一个空表修改字段，完全可以通过，我们创建新的迁移文件，然后在 up 方法内这样调用：

$table->string('name', 100)->change();

看，只用调用一个 change 方法，就搞定了。这个方法最终使用的是类似下面的SQL语句：

alter table `users` alter `name` varchar(100);

当然还可以对字段的默认值约束进行修改：

$table->string('deleted_at')->nullable()->change();

对于插入新的字段，还可以指定位于哪个字段之前或者之后：

$table->string('email')->nullable()->after('last_name');

仅仅修改字段名，只需调用对应方法：

$table->renameColumn('promoted', 'is_promoted');

或者在回滚方法中对某些新增的字段进行删除：

$table->dropColumn('votes');

常用的约束比如主键约束，联合主键约束，唯一性约束，和索引约束。也可以很方便地在声明表，或者修改表的时候进行调用：

$table->primary('primary_id'); // 指定主键
$table->primary(['first_name', 'last_name']); // 联合主键

还有唯一性约束，为存在的字段创建：

$table->unique('email'); // 唯一性
$table->unique('email', 'optional_custom_index_name'); // 指定索引名

为字段创建索引：

$table->index('amount'); // 索引
$table->index('amount', 'optional_custom_index_name'); // 指定索引名

过于复杂的数据库方面的约束，触发器，存储过程，事务等等，是我们所不提倡的，因为溯源有些困难。上面给的这些个方法，足够应对很多很多场景了。

写在最后

本文介绍了laravel中使用迁移功能操作数据库的创建，修改，移除字段，删除表等，把开发者从手动维护数据库的状态中解脱出来。这样也为团队协作时的有章可循做了铺垫。

成熟的开发团队，应该有规范的制度，特别是底层的数据库结构，大家约束在编程层面，方便使用代码库管控和全程追溯。这非常值得推荐。

Happy coding :-)

我是@程序员小助手，专注编程知识，圈子动态的IT领域原创作者