Организация базы данных: Миграции

Mar 20, 11:10 pm Категория:

После всех отступлений и других телодвижений я опять добрался до базы, мать их, данных. В небольшой статье, посвящённой анализу базы Textpattern я вплотную подошёл к проектированию базы данных нового сайта на Laravel. Чтобы наше шоу не продлилось вечно, я напомню о том, что Laravel – это фремворк для веб-ремесленников. А значит, что главное результат, а не теория. Поэтому буду краток. Если получится.

Мне нужна база данных Laravel для переноса в неё данных из Textpattern. Можно, разумеется, сделать её “ручками”, но лучше по правилам. Для этого в Laravel используется механизм миграций. В корне свежеустановленного Laravel есть директория database, в которой есть два файла:

database/migrations/2014_10_12_000000_create_users_table.php
database/migrations/2014_10_12_100000_create_password_resets_table.php

По названию понятно, что это про пользователей и сброс пароля. Миграции используются для создания, удаления и разнообразных изменений таблиц базы данных. В предыдущей публикации я их уже накатил. Фишка миграций в том, что база данных легко создаётся, переносится, модифицируется и, если потребуется, откатывается к предыдщущим состояниям. Сейчас я как раз удалю все В документации миграциям выделена целая глава, в которой описано чокак. Для заливки данных в базу у Laravel тоже есть свои механизмы, но я ими пользоваться не буду. Хотя… Напишу маленькую статейку и о посеве данных.

А пока к делу базирования данных. Я планирую:

  • Изменить оригинальную таблицу и модель пользователей;
  • Создать таблицу и модель статей;
  • Создать таблицу и модель изображений;
  • Создать таблицу и модель комментариев;
  • Создать таблицу и модель тегов;
  • Создать таблицу и модель категорий;
  • Создать таблицу и модель циклов статей;
  • Связать статьи и теги через таблицу;
  • Связать статьи и категории через таблицу;

Это не окончательная версия базы, но я уже писал, что внести изменения можно в любой момент, а поскольку данные я буду заливать своим скриптом, и мне не требуется мерджить локальные и внешние данные, то вообще ниикаких проблем с экспериментами нет. По поводу отсутствующих секций и каких-то ещё данных: я не забыл, их действительно нет. У таблиц связи (пивотов) нет и моделей. Теги и категории – это похожие сущности, но категории могут иметь декор, а теги – только имя и слаг (slug – так тут принято называть часть URL, созданную из заголовка или слова).

А а теперь серия команд в консоли:

./artisan make:migration alter_users_table
./artisan make:model Article -m
./artisan make:model Image -m 
./artisan make:model Comment -m
./artisan make:model Tag -m
./artisan make:model Category -m
./artisan make:model Cycle -m
./artisan make:migration --create=articles_categories create_articles_categories_pivot
./artisan make:migration --create=articles_tags create_articles_tags_pivot

В первой строке я создаю миграцию для изменения таблицы пользователей с именем, которое не оставляет сомнений в назначении файла. Затем идут 6 строк про создание модели и миграции под неё. Имена моделей здесь принято писать с заглавной буквы, а миграций этом формируются автоматом и строятся на основе множественного числа модели, для которой генерируется миграция. Наконец последние две строки для создания таблиц связи. В имени файла присутствуют оба имени связываемых моделей. Порядок следования имён – по алфавиту. Результат – 6 моделей и 9 миграций.

Если Laravel не понимает, чего от него хотят, он создаёт практически пустые шаблоны миграций. Если же он видит смысл в командах, то добавляет в шаблоны имена таблиц баз данных, команды генерации индекса и дат создания и модификации записи. Подробности в документации. Пустой шаблон миграции выглядит так:

<?php

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

class AlterUsersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        //
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        //
    }
}

Функции up() и down() определяют действия при накате и откате миграции. Можно таблицы создавать, можно менять, можно удалять. Поля можно добавлять, можно переименовывать и т.п. Оригинальная миграция 2014_10_12_000000_create_users_table.php создаёт таблицу users с семью полями при установке и подчистую её удаляет при откате.

<?php

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

class CreateUsersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    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();
        });
    }

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

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

<?php

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

class AlterUsersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('users', function (Blueprint $table) {
            $table->renameColumn('name', 'first_name');
            $table->string('nik')->unique()->after('id');
            $table->string('last_name')->after('first_name');
            $table->string('site')->after('email')->nullable();
            $table->string('avatar')->after('site')->nullable();
            $table->softDeletes();

        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('users', function ($table) {
            $table->string('name')->after('id');
            $table->renameColumn('first_name', 'name');
            $table->dropColumn(['nik', 'last_name','site','avatar','deleted_at']);

        });            
    }
}

В функции up() я переименовываю одно поле, создаю несколько новых и задаю нужные свойства этим
полям типа порядка следования, уникальности и т.п. Строка $table->softDeletes(); создаёт поле deleted_at. Функция down() возвращает таблицу в то состояние, что было до начала работы up(). Если таблица создавалась, то она должна быть удалена, если таблица менялась, то изменения откатываются до предыдущего состояния. Элементарно.

Всё понятно? Теперь идём на сайт Laravel Schema Designer и делаем всё то же самое и кое что ещё с помощью мышки. Кроме миграций создаются модели, маршруты и контроллеры. Скорее всего для запуска в работу потребуется напильник, но экономия времени при создании и возможность редактировать в процессе делает инструмент очень интересным. Особенно в моём случае, когда нужны только таблицы.

Ну а я пока буду экспериментировать с оптимальным видом базы данных, делать скрипт для импорта и думать, во что и как переделывать сайт. Что-то не хочется мне использовать старую вёрстку. Не стоит она того, чтобы дважды над ней голову ломать. Наверное посмотрю в сторону Bootstrap - в Laravel видны какие-то его следы.

Теги этой статьи: , ,

 

Комментарии

2017-12-11 1:19 am , Оставь комментарий