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

В прошлый раз мы подключили наше новое приложение Rails к нашей базе данных PostgreSQL. Сегодня мы добавим несколько таблиц.

Есть вещь, называемая схемой базы данных.

«Схема» — это просто красивое слово для структуры базы данных: ее таблиц и столбцов каждой таблицы. Пришло время их спроектировать.

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

Акты, площадки, концерты. Очень просто. Правильно?

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

Действует: удостоверение личности, имя.

Места проведения: ID, название.

Концерты: идентификатор, идентификатор акта, идентификатор площадки.

Давайте сделаем так, чтобы это произошло. Новая функция, поэтому создайте новую ветку.

$ git checkout -b 2-create-schema
Switched to a new branch '2-create-schema'
$ git branch
  1-connect-database
* 2-create-schema
  master

В Rails (точнее, в ActiveRecord) есть такие штуки, которые называются миграции. Они не уникальны для Rails, они довольно распространены в мире веб-разработки. Файлы миграции — это серия сценариев Rails, используемых для отслеживания изменений в базе данных вашего приложения. Если вы новый член команды существующего проекта с долгой историей, вы можете просто запустить все существующие файлы миграции, и они создадут вашу базу данных с нуля. Тогда она будет идентична базам данных всех ваших коллег на их машинах. Сладкий.

Зачем заморачиваться с миграциями? Почему бы просто не изменить базу данных напрямую, вручную? PostgreSQL имеет собственную командную строку, как MacOS и Linux, и вы можете полностью добавлять и удалять таблицы и их столбцы оттуда.

Проблема в том, что может быть сложно отслеживать эти изменения среди разных членов группы кодирования, каждый из которых имеет свою собственную локальную базу данных на своем локальном компьютере. Или, может быть, менеджер вашего проекта решил сменить вашу СУБД с PostgreSQL на MySQL или вообще на другую.

Давайте сделаем миграцию Rails.

$ rails generate migration CreateActsGigsVenuesTables
Running via Spring preloader in process 9481
      invoke  active_record
      create    db/migrate/20190910020025_create_acts_gigs_venues_tables.rb

Краткое пояснение: Rails поставляется с собственной программой командной строки, которая по удивительному совпадению называется rails. Как и Git, он принимает свои собственные команды, одна из которых — generate, а мы генерируем migration. Миграции похожи на коммиты и ветки в том, что их точные соглашения об именах немного расплывчаты, вы можете честно называть их как угодно, но лучше всего делать их краткими.

Вы увидите, что он создал новый файл. Давайте откроем его.

Имя файла состоит из двух частей: строки чисел даты и времени (ггггммддччммссмммм — годы, месяцы, дни, часы, минуты, секунды, миллисекунды), затем имя в формате подчеркивания, которое мы дали миграции.

Каждый файл миграции — это вещь, называемая классом (для тех из вас, кто изучал объектно-ориентированное программирование, да, это такой класс). Все классы миграции имеют один метод change. Он будет содержать желаемые изменения базы данных.

Мы изменим содержимое метода change следующим образом:

def change
  create_table :acts do |t|
    t.string :name
  end
  create_table :venues do |t|
    t.string :name
  end
  create_table :gigs do |t|
    t.references :acts
    t.references :venues
  end
end

(Star Trek РЕДАКТИРОВАТЬ: кстати, если вы уже опытный разработчик Rails, вы можете подумать: подождите, нет t.timestamps? Что дает? Упс! Я действительно забыл добавить их сейчас , и не ловил мое упущение до статьи 18).

Каждая таблица на основе Rails-миграции по умолчанию включает идентификатор, поэтому нам не нужно писать его самостоятельно. Но в противном случае он создает столбец name для Acts и Venues, а для Gigs создает act_id и venue_id.

Теперь запускаем.

$ rake db:migrate
== 20190910020025 CreateActsGigsVenuesTables: migrating =======================
-- create_table(:acts)
   -> 0.0572s
-- create_table(:venues)
   -> 0.0049s
-- create_table(:gigs)
   -> 0.0181s
== 20190910020025 CreateActsGigsVenuesTables: migrated (0.0806s) ==============
== 20190910020025 CreateActsGigsVenuesTables: migrated (0.0806s) ==============

Теперь мы внесли желаемые изменения в базу данных. PostgreSQL содержит эти новые таблицы.

Теперь, чтобы зафиксировать наше изменение, наш новый файл класса миграции. Во-первых, git status, чтобы просмотреть, что мы собираемся зафиксировать.

$ git status
On branch 2-create-schema
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        db/migrate/
        db/schema.rb
nothing added to commit but untracked files present (use "git add" to track)

Вау Нелли. Еще один новый файл! Что такое db/schema.rb? Большая тема. Я не буду дублировать здесь превосходные руководства по Rails, поэтому, если хотите, прочитайте их страницу в файлах схемы.

Так или иначе. Вперед!

$ git add .
$ git status 
On branch 2-create-schema
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
        new file:   db/migrate/20190910020025_create_acts_gigs_venues_tables.rb
        new file:   db/schema.rb
$ git commit -m "Created and ran our first schema migration"
[2-create-schema 4ab6678] Created and ran our first schema migration
 2 files changed, 49 insertions(+)
 create mode 100644 db/migrate/20190910020025_create_acts_gigs_venues_tables.rb
 create mode 100644 db/schema.rb

Сделанный. Вы можете увидеть всю кодовую базу этого коммита здесь.

Наконец, объедините нашу ветку создания схемы обратно в master.

$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
$ git branch
  1-connect-database
  2-create-schema
* master
$ git merge 2-create-schema
Updating 163cd85..4ab6678
Fast-forward
 db/migrate/20190910020025_create_acts_gigs_venues_tables.rb | 16 ++++++++++++++++
 db/schema.rb                                                | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 49 insertions(+)
 create mode 100644 db/migrate/20190910020025_create_acts_gigs_venues_tables.rb
 create mode 100644 db/schema.rb

Законченный!

Здорово. Мы создали шаблонное приложение Rails. Мы подключили его к базе данных. Мы создали для него несколько таблиц. Теперь давайте заполним его данными.

В следующий раз: мы подключим наше приложение к Ticketmaster API и начнем получать данные о его милых концертах.