"Голый SQL на прошлой работе" - это sql-скрипты с инкрементальными

Question

"Голый SQL на прошлой работе" - это sql-скрипты с инкрементальными

миграциями? Заморачивались ли вы идемпотентностью скриптов и была ли от нее реальная польза хотя бы раз?

Сейчас у вас подход с diff-ами схем и накаткой сгенерированной разницы? Везде и у всех одинаковая БД или имеются отличия между средами dev/test/prod или клиентами?

Чем FluentMigrator и миграторы вообще сильно выигрывают у простого прямого SQL, чтобы усложнять все этой дополнительной прослойкой, я тоже пока не понимаю. Откаты в реальности тоже почти не требовались, и не хочется ради этих редких единичных случаев усложнять регулярные миграции.

#backend #dot #programming #russian

0

29.04.2019

1 ответов

9 просмотров

Vabka · Accepted Answer

идемпотентностью не заморачивались, тк пилили голый DDL + инсерты всяких константных значений. Ни разу за год не стукнуло это по голове. Всякие сложные вещи делали скриптом, который прогонялся вручную. При тестировании автоматическом вся схема дропается и пересоздаётся. При тестировании ручном и на проде накатывается diff. Разрабы соответственно коннектятся к тестовой базе, либо inmemory. С мигратором я подробно рассказать не могу, тк поработал с ним пару дней, но ощущения не оч были. Нужно как-минимум что-то поверх него вешать и не закидывать туда не всё подряд (всякие тривиальные вещи по типу создания новой колонки/индексов итд проще через diff делать) (имхо)

170 похожих чатов

"Голый SQL на прошлой работе" - это sql-скрипты с инкрементальными

1 ответов

Похожие вопросы