я разработчик простой, вижу новый видос Егора - ставлю лайк)

Может я чего-то не понимаю, но мне кажется, что миграции бд это не такой сложный вопрос чтоб так его раздувать. Я работаю в основном на питоне и там alembic решает для меня проблему миграций уже давно и довольно успешно. Файлы миграций лежат в репе рядом с исходным кодом, на каждый коммит или PR миграции прогоняются в CI. В случае если разные разработчики сделали разные миграции в своих ветках, то CI попросту сломается. UPD: Сорр, не заметил, что это лекция для универа. В таком контексте лекция норм, мне в колледже вообще втирали, что все в проде используют MS SQL, а изображения всегда нужно хранить в СУБД как бинари, и ни в коем случае не складывать их на диск или, еще хуже, в S3. Если бы у меня был такой препод, может я бы и ходил туда почаще.

Вначале подумал, что Егор заново изобретает миграции, но потом понял - это учебная лекция 😁

Насчет того, зачем нужен индекс, созданный в файле *004*.xml (1:16:26) тут может помочь git, если посмотреть на git annotate на строку, содержащую CREATE INDEX, то можно найти какой код менялся одновременно с добавлением этого индекса и понять логику. Так что может быть, комментарий не так уж обязателен или по крайней мере, ситуация с его отсутствием не безнадежная.

Слышал от вас, Егор, что в начале пути разрабатывали базы данных. Круто, что есть такой контент на ютюбе. Ждём всей командой чёрно-белые айти)

Как философская и идеологическая - лекция хороша, спасибо. На практике при сложных базах вряд ли получится такого идеала достигнуть, хотя стремиться к полному управлению проектом из VCS - нужно.

После просмотра видео остался вопрос, что делать с инсертом тестовых данных в продовую таблицу. За видео спасибо, очень полезно и понятно

И, если будет возможность, в черно-белом айти, хотелось бы послушать про мёрдж, бранч, гит и альтернативы ему, типо нотебаг, особенно во времена, когда гитхабный опер сорс под Майкрософт становится постепенно цензурируемым большим братом)

Для больших и сложных баз такой метод не подойдёт. Не получится каждый раз создавать всю базу с нуля. Вероятно, система должна быть посложнее. Чтобы скрипты позволяли не только монотонно инкрементить состояние базы, но и назад откатывать. Путь даже не очень далеко. Хотя бы до той точки, которая в продакшене.

Когда будут новые выпуски Черно-белого айти? Ждём 🙂

Егор сниимите пожалуйста видео почему вы уехали из США

Дропать таблицы это, конечно, весело, особенно прямо на проде, но с данными то что делать ? Я бы их куда то сохранил, передропал всё, изменил структуру и залил обратно, но как ?

Так а почему это не разбирается на существующих инструментах для миграций? зачем писать велосипед, который оторван от текущих практик по этому вопросу. Я бы понял если бы использовался устаревшая тулза, но которая раньше использовалась …

Я только не понял как же отлаживать все запросы, если даже тестовой базы нет?

А нет смысла squash'ить схему базы данных хотя бы раз в год? Скажем, раз в major release. Я понимаю, что Liquibase хранит md5 и так просто не даст это сделать в продакшн. Но получается, как будто мы код храним в git не в виде целых файлов, а в виде diff'ов и через год разработки неудобно, что нет места, где можно посмотреть полную или почти полную схему. Плюс, возможно, запуск тестов будет существенно замедлен, если перед ним нужно будет применить все changesets к БД с начала истории проекта. В идеале, мы могли бы хранить схему и миграции, а по изменениям схемы в git liquibase строил бы ALTER TABLES.. Или хранить схему, плюс то, что отличает ее от предыдущей ревизии, чтобы liquibase накатывал изменения, двигаясь по истории в git.