Rails - авторитетный источник для вашей схемы базы данных?

Question

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

Итак, мой вопрос:

• Каков официальный источник вашей схемы в проекте Rails?
• Что в настоящее время считается наилучшим способом поддержкиваша схема БД?

Answer 1

Я не считаю миграцию официальным источником вашей схемы. Миграции чрезвычайно мощные, но необязательные. Некоторые разработчики используют альтернативные рабочие процессы, особенно в средах, где администраторы настаивают на строгой ссылочной целостности и ограничениях, установленных СУБД. Я предлагаю взглянуть на официальное Руководство RoR по миграции для получения дополнительной информации. Файл db/schema.db (или db/{env}_structure.sql) является официальным источником вашей схемы. Многие разработчики удаляют старые миграции по мере старения проектов, поэтому при выполнении каждой миграции не обязательно будет работать рабочая база данных. Также требуется много времени, чтобы пройти через сотни миграций. Rails использует schema.db (или файл дампа sql) для создания тестовой базы данных и, конечно, при запуске rake db:setup, который является рекомендуемым способом создания новой базы данных для вашего приложения.

Суть в том, что rake db:setup всегда должен создавать рабочую базу данных независимо от миграций. Разработчики могут использовать это для создания новых сред, а Rails использует это для запуска ваших тестов.

http://guides.rubyonrails.org/migrations.html#schema-dumps-and-source-control

Answer 2

Обычно выполнение последовательности всех миграций должно приводить к созданию вашей фактической схемы БД (если это не так, значит, вы не правильно использовали свои миграции *).

Другой способ сделать это - скопировать файл schema.rb (созданный / обновленный при переносе), который используется rake db:setup и должен создать точную копию схемы, имеющейся у вас в работе (если, опять же, вы неправильно использовали миграции *).

Затем, если вам нужны «образцы данных», вы можете вставить их с помощью файла db / seed.rb, который содержит код ruby, который может получить доступ к вашим моделям, и, таким образом, создавать и сохранять новые сущности и так далее ...

*: Существуют случаи, когда вы не можете поместить все изменения в вашей базе данных в миграции «обычным» способом (это необычно и следует избегать, если это возможно) ... Однако они должны быть включены в миграции (в простом виде) Операторы выполнения SQL), или изменения также должны быть внесены вручную в dev DB ... а затем с помощью снимка prod. иногда удобнее. Но опять же, я бы не рекомендовал это делать.