Блог

Я программист на PHP более десяти лет и перехожу на RoR. Вот к чему я привык из мира PHP:

1. Создайте схему БД в таком инструменте, как MySQL WorkBench, и сделайте поля именно того размера, который я хочу, не тратя впустую пространство (например, varchar(15), если это ip_address).
2. Напишите модели с использованием Datamapper и поместите туда эти точные длины полей и спецификации, чтобы мое приложение не пыталось вводить какие-либо большие значения.

В мире RoR, судя по тому, что я видел за последние два дня, это, похоже, предложенный поток:

1. Добавьте поля / схему с помощью командной строки, которая создает сценарий миграции и, по-видимому, создает большие поля ass (например, «строка ip_address», вероятно, создает поле varchar (255) в БД при запуске миграции).
2. Вводите проверки во время создания модели.

Я что-то здесь упускаю? Каков процесс в мире RoR для приложений корпоративного уровня, где вы действительно хотите создать настраиваемую схему? Должен ли я вручную выписывать сценарии миграции?

Строительные леса — это то, что вы используете для быстрого начала работы. Но перед запуском миграции вы можете отредактировать ее и добавить ограничения и определенные длины столбцов.

Проверки, указанные в модели (в коде ruby), не обеспечивают тот же уровень безопасности, что и проверки / ограничения, указанные в базе данных. Таким образом, вам все равно нужно определить их в базе данных.

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

Вы можете отредактировать сценарии миграции перед запуском миграции, чтобы настроить поля.

Да, если вам нужно настроить значения по умолчанию, вы редактируете сценарии миграции.

Также обратите внимание, что вам не нужно использовать миграции, они «удобны» при повторении разработки БД. Ничто не говорит о том, что вы должны их использовать. Шаблон активной записи не зависит от того, как создаются или определяются таблицы / поля / и т. Д. БД.

Например, миграции бесполезны при работе с устаревшими базами данных, но вы все равно можете написать приложение Rails вокруг них.