Comments 23
raw SQL vs PHP api
ORM в миграциях нужна не столько для «удобства», сколько для потенциальной возможности смены СУБД, при чистом SQL придется его переписывать, с ORM — нет. Конечно при специфичных моментах в диалектах это не поможет, но переписывать в любом случае придется меньше. + превратить orm код в чистый sql легко, в отличие от обратного
Транзакции в DDL
Почему только Postgress? К чему этот пункт? Разве есть современные субд, которые не поддерживают транзакции?
Разве есть современные субд, которые не поддерживают транзакции?
ORM в миграциях нужна не столько для «удобства», сколько для потенциальной возможности смены СУБД
В миграциях этого точно не нужно — они одноразовые.
Транзакции в DDL
НЕ все базы поддерживают транзакции на уровне запросов по изменению структуры БД.
Долго работал и мучался с MySQL, у которой этого не было. Как там сейчас уже не в теме.
И большинство из них работают с миграциями — командами для внесения инкрементных изменений в схему базы данных.
Я не очень глубоко влазил в Doctrine по этому вопросу, но у меня сложилось впечатление, что Doctrine DBAL считывает текущую схему данных из базы, позволяет разработчику через PHP-код модифицировать её путем удаления/добавления таблиц/столбцов, затем сама генерирует набор SQL-запросов, переводящих структуру данных из начального состояния в желаемое.
Разумеется, что делает она это не настолько хорошо, как это может сделать сам разработчик на чистом SQL, заточенном под конкретную СУБД, но меня во всём этом привлекает идея создания моделей схемы данных — начальной и конечной. Doctrine создает модель в памяти из PHP-объектов, но можно модель описывать в виде XML/JSON/YAML/… В этом случае вся схема данных, допустим в XML, ложится под стандартный контроль версий (как и SQL-файлы).
Для двух различных моделей схем данных можно прогонять миграцию прямую и обратную (rollback). Два развития одной базовой модели от двух (и более) разных девелоперов можно прогнать через процедуру слияния (текст структурированный), либо вообще собирать конечную модель из отдельных фрагментов, где каждый девелопер сам развивает свой участок общей схемы данных.
Для таблиц такой структурированный подход уже работает (Magento 2.3). Для views/triggers/procedures/… более проблематично (здесь, скорее всего, пойдут вставки чистого SQL, что нивелирует преимущества структурирования информации).
Тем не менее, если не увлекаться DB-программированием (триггеры и SQL-процедуры), то можно достаточно успешно структурировать SELECT, который лежит в основе создания views. А tables & views — основа схемы данных. Т.е., если переводить XML/JSON/YAML-модель в Doctrine-модель, то далее Doctrine DBAL уже сама сможет выполнять миграцию.
Это не универсальное решение, оно однозначно не подойдёт для крупных проектов, где БД является центром Вселенной и доводиться вручную "до блеска". Но для проектов, типа Magento, где конечное приложение собирается из отдельных модулей (как следствие, конечная схема данных собирается из отдельных фрагментов) — может оказаться вполне удачным.
Мы пишем миграции на чистом SQL. Многие инструменты предоставляют PHP-api для написания инструкций транслируемых в SQL-код. Теперь я вообще не понимаю зачем это?
Есть такие штуки, как продукты, которые должны работать с любыми SQL-базами. CMS, например. Это не про модели и константы, которые да, меняются. Это про DSL в самих миграциях.
как посмотреть историю изменений конкретного объекта структуры БД. По каждой таблице хочется посмотреть историю изменений в связи с решением конкретных задач.
Для этого нужно вести не только миграции, но и полноценное версионированное описание схемы. Больше того — это описание первично по отношению к миграциям (которые всего лишь описывают один из бесконечного числа возможных путей перевода БД из состояния А в состояние Б).
Но в комментариях к одной из приведённых статей звучали термины state-driven deployment и change-driven deployment.
Общая идея, в целом, достаточно проста: у вас должны быть скрипты, описывающие состояние схемы. Из них можно в любой момент собрать любую версию БД «с нуля» (и по ним же посмотреть кто, что и когда изменил). А миграции — это отдельная часть проекта (вторичная по отношению к схеме), причём имея в системе контроля версий состояния вы всегда можете убедиться в том, что ваша миграция делает именно то, что вы хотели (собрав с нуля схему версии N, а рядом версии N-1 + накат на неё миграции и сравнив их между собой).
Это если вкратце.
mysqldump --add-drop-table --no-data --routines $DBNAME > $SCHEMAИмпорт чуть более сложен, но только из-за добавленой интерактивности. Схема разбивается на части и выполняется по частям. Это позволяет видеть процесс по каждой таблице и сразу загружать её данные. Данные так же грузим частями, чтобы был виден прогресс и чтобы не спотыкаться на размере буфера. У нас в схеме больше сотни таблиц, некоторые словари имеют десятки тысяч записей и занимают несколько мегабайт. Без такой разбивки процесс импорта весьма скучен :)
// search for all tables in the schema
if (preg_match_all('%\s*DROP\s+TABLE\s+(?:IF\s+EXISTS\s+)?(?#
)\`([a-z_A-Z]+)\`.+(?=DROP\s+TABLE|\/\*\!\d+\s+DROP\s+FUNCTION(?#
)|\/\*\!\d+\s+DROP\s+PROCEDURE)%sU', $sSchema, $aMatches))
{
$sSql = '';
foreach ($aMatches[1] as $i => $sTable)
{
$this->write(sprintf(' > create table %s ...', $sTable));
$sSql = $aMatches[0][$i];
// apply global settings from sql dump header
if ($i === 0)
{
$sSql = substr($sSchema, 0, strpos($sSchema, $sSql))
. $sSql;
}
$iTime = microtime(true);
// clear auto increment value
$sSql = preg_replace('/AUTO_INCREMENT=\d+/', '', $sSql);
Yii::app()->db->createCommand($sSql)->execute();
$this->write(sprintf(' done (time: %.3fs)' . PHP_EOL,
microtime(true) - $iTime));
$this->loadTableData($sTable);
}
// leave only routines in schema
$sSchema = substr($sSchema, strpos($sSchema, $sSql) +
strlen($sSql));
}
// and then routines
if (preg_match_all('%(?:/\*!\d+\s+)?DROP\s+(FUNCTION|PROCEDURE)\s+(?#
)(?:IF\s+EXISTS\s+)?`([a-z_A-Z]+)`.+\sDELIMITER\s\;\;(.+)\;\;(?#
)\s+DELIMITER\s\;\s%Ums', $sSchema, $aMatches))
{
foreach ($aMatches[2] as $i => $sName)
{
$this->write(sprintf(' > create %s %s ...',
strtolower($aMatches[1][$i]), $sName));
$sDropSql = preg_replace('/;.+$/Ss', '', $aMatches[0][$i]);
$iTime = microtime(true);
// drop function or procedure if exists
Yii::app()->db->createCommand($sDropSql)->execute();
Yii::app()->db->createCommand($aMatches[3][$i])->execute();
$this->write(sprintf(' done (time: %.3fs)' . PHP_EOL,
microtime(true) - $iTime));
}
}
На mysql вот этой штукой можно. Недавно внедрили, храним схему базы, в git
Впервые об этом я узнал, когда по неопытности локнул таблицу на 4 часа…
После чего приходится использовать percona-toolkit, которая создает временную таблицу с новой структурой, а на старую цепляет триггеры. Это позволяет делать редактирование таблиц без простоев.
Как я понимаю, эта проблема актуальна не для всех баз, но подобная ошибка может быстро отучить от использования миграций на больших таблицах.
Придумали ли какое-то решение для этого сценария?
Опыт 1440 миграций баз данных — habr.com/company/wrike/blog/414441
Колонка добавляется как nullable ну и дальше аккуратно заполняется.
как посмотреть историю изменений конкретного объекта структуры БД. По каждой таблице хочется посмотреть историю изменений в связи с решением конкретных задач.
Вот тут и тут рассказывалось об очень удобной тулзе RedGate SQL Compare. Использовали на проекте одном, вполне годная для версионирования изменений в базе данных, но конфликты она решать не умеет (например при добавлении not null поля в существующую таблицу с данными).
Также в Phalcon Framework видел хорошее решение подобной проблемы, но там тоже не нативный SQL, а DSL описание бд (тут).
PHP: изменение стуктуры БД в командной разработке