Pull to refresh

Comments 39

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

Мне кажется. с таким же успехом можно просто заходить на сервер и править код. Какая разница то, срочные правки же!

Править код на проде — последнее дело. Не знаю, почему это так популярно в среде разработчиков БД. Еще и преподносится как хорошая практика…
Вот вам пример из жизни

Бизнесу надо запретить почти всем пользователям выполнять операцию, которая раньше была вполне себе легитимной. Например сделать это новой настройкой уровня доступа. Естественно рассылаются новые должностные инструкции пользователям, согласовывается новое ТЗ/ЧТТ на изменение функционала поддерживаемой системы.
И конечно ждать его величество Бизнес очень не любит.

Что лучше?
Воткнуть триггер сегодня чтобы пользователи гарантированно перестали делать чего они не должны, и затем выкатить новый релиз по стандартной схеме?
или уповать на новые инструкции в ожидании релиза?
или запускать процесс обычного нового ЧТТ/ТЗ по аварийной схеме с максимально быстрой выкаткой?
Лично я на подобные случаи стараюсь иметь несколько вариантов решения:
1) механизм релиза-хотфикса, который можно катить в любое время и который не блокируется текущими доработками
2) механизм для запуска миграций

Оба варианта выше в любом выкатываются из репозитория и предварительно проходят Code Review.

Еще хочу заметить, что бывает так, что даже во внутренней разработке может не быть доступа на запись в прод-базу у разработчиков, например, из-за требований внутреннего или внешнего аудита.

Да достаточно попасть под действие Sarbanes-Oxley Act (например, начать листиться на американской бирже и работать с деньгами), и у разрабов не будет никакого write-доступа ни к данным, ни к рабочему коду, все деплои только через код-ревью в 4 глаза.

Да, SOX быстро заставляет даже не думать о «бизнес захотел быстро и я пошел на прод»
А вас не затруднит привести пункт в этом акте относительно этого вопроса?

Если честно, то я даже и не читал этот закон. К нам в один прекрасный день пришли аудиторы, посмотрели на разрабов, провели интервью с ними, посмотрели, как мы храним и пишем код, как релизим, и т.п… А через полгода из материнской компании спускают требования следовать рекомендациям, а там и отбор доступа у разрабов в прод, и вот это вот все. Но радует, что CI/CD-пайпалайн и зеленый мастер удалось отстоять.

Вообще в самом акте про доступ разработчиков вообще ничего не говорится, он про деньги.
В комментариях вполне разумные требования — чтобы на продакшене не болтался непойми кто, чтобы пароли менялись, чтобы бывшие сотрудники не сохраняли доступ и т.д.
Помимо прочего требуется иметь дизастер рикавери план — что делать в случае факапа. Судя по комментариям факап представляется такой мерзостью, о которой и думать противно; вот никто и не думает.
То есть вы за вариант «запускать процесс обычного нового ЧТТ/ТЗ по аварийной схеме с максимально быстрой выкаткой»? просто потому что Бизнес захотел быстро?

Вариант с отсутствием доступа вообще весь тред делает бессмысленным, поэтому предлагаю его не рассматривать.
Пусть без прямого доступа, но передать временную «миграцию» отдельно от общего решения всегда можно. Отличаться от прямого доступа это будет только в части того кто будет запускать скрипт.
Да, именно такой вариант. Если что-то надо срочно для бизнеса, то можно форсить рабочий процесс, а не начинать работать мимо процесса, CI, тестов и всего прочего, что делает разработку надежнее.

На своих проектах я стараюсь добиться того, чтобы накат, в том числе и bugfix-ов и hotfix-ов, был не болью, а быстрым и понятным процессом.
На своих проектах я стараюсь добиться того, чтобы накат, в том числе и bugfix-ов и hotfix-ов, был не болью, а быстрым и понятным процессом.

с подобным стремлением нельзя не согласиться.

А что мешает делать это через систему конфигурации или, о боже, добавить в приложение настройки прав для пользователей, которые можно хранить в бд? Более того, почти все системы так и делают.


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

А что мешает начать читать внимательно?

Бизнес не требовал раньше подобное разграничение доступов. Почему же его надо было заранее делать? Теперь ограничение потребовалось. Вся суть примера в изменившихся требованиях и вариантах их реализации.

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

Идея оставить заказчика наедине с его проблемами до ближайшего релиза не предоставляя обходных решений еще хуже.
Дело не в плохости «добавить на скорую руку какой-то триггер». Если триггер взвели и одновременно с этим в системе контроля версий он тоже появился и в реализуемом постоянном решении это учтено, то получаем win-win. Бизнес доволен оперативностью и спокойно ждет оплаченную доработку. Разработка довольна, что не надо делать все аврально.
Если триггер взвели и одновременно с этим в системе контроля версий он тоже появился и в реализуемом постоянном решении это учтено, то получаем win-win.

Так же можно и сразу менять код на проде, с бекпортом в репу. Проблема в том, что этот код не тестируется, не проходит CI и прочее-прочее-прочее. И, обычно, приводит к еще большим авралам.


Бизнес не требовал раньше подобное разграничение доступов. Почему же его надо было заранее делать?

Я, конечно, дико извиняюсь, но есть вещи, которые подразумеваются в системе для бизнеса. Эта как раз одна из них.

Можно любую ситуацию доводить до абсурда. Менять код БД на несколько порядков проще чем менять код JavaEE какой-нибудь. Об этом и говорится в статье.

Мой изначальный коммент был про то, что возможны ситуации, когда изменение кода в БД на проде даст быстрый желаемый результат без тяжелых последствий.
Это не значит что надо переходить на Production Driven Development.
Это значит, что при рассмотрении конкретной ситуации, надо учитывать подобную возможность.
Если система доставки спроектирована как рассказывает VladimirVerstov
выше, то подобная возможность не будет использоваться.
Если система доставки нового кода от 4х недель и больше, то нельзя догматично отбрасывать возможность спасти больше данных заказчика прямым вмешательством (и конечно работать в сторону уменьшения времени доставки).
Мой изначальный коммент был про то, что возможны ситуации, когда изменение кода в БД на проде даст быстрый желаемый результат без тяжелых последствий.

Количество таких ситуаций настолько мало, что рассматривать их всерьез не имеет смысла. То есть, если ваше приложение изначально разрабатывалось с прицелом на использование триггеров, то это еще пол беды (но это опять же сравнимо с Production Driver Development), а если нет, то вы вполне вероятно отхватите столько багов, что вполне возможно, дождетесь следующего релиза.

«Количество таких ситуаций настолько мало»
Мало.
Но одного раза может быть достаточно для прикрытия бизнеса.
Мне хотелось бы увидеть метод, как можно реализовать какое-нибудь «немедленно уберите Пупкиных отовсюду, сию же секунду!!!11»
Ответ «через недельку, бог даст, выкатим» не считается — ну или пусть программист оплачивает потери бизнеса самостоятельно.

Имхо, все эти рекомендации актуальны практически для любой реляционной субд. Не считая мелких различий, общие принципы остаются везде одни и те же. Начиная с антикварных Адабас и SystemR образца 1971 года.
И вообще, спасибо товарищам Бойсу и Кодду, за создание стройной и красивой теории баз данных.

Правила полезные, нужно однозначно их распечатать, чтобы были как знаки в ПДД — всегда на виду. Спасибо!
Не надо это никуда печатать. Тут всё довольно спорно.
К сожалению, в расшифровку не попало вступление. В нем я рассказывал, что
1. Я не самый умный
2. После выступления обязательно найдутся три типа граждан
2.1 «Вот она, правда!»
2.2 «Это спорно»
2.3 «Это полный бред»
Ваши 3 типа граждан это такие:
2.1 — данных 100 МБ
2.2 — данных 100 ГБ
2.3 — данных 100 ТБ
Ваши рекомендации для 2.1, просто в статье это не указано (может я пропустил)
Ну вот видите, как вы славно умеете классифицировать. Это же замечательно!
Про «подкорячивание кода на проде наживую» не согласен. Ничем не лучше непроверямого код фикса и выката версии приложения в те же сроки — приведет к тем же проблемам (что-то не протестировали нормально и оно подохло вместе с данными)

Уже 10 лет как не смешно про удобство кода в базе, я уже не говорю про "долгую" компиляцию и выкладку, когда все на микросервисах с автодеплоем. Это базизм головного мозга — когда ты базист, код в базе кажется самым удобным)))

А, ну а как же. Приходили подобные люди, устроили себе сплитбрейн на одной базе.
Если вам требуется «select 1 from dual», то оно конечно хорошо и можно заряжать ваш ORM. Но когда надо производить реальные манипуляции с данными, я не понимаю, как ваш «уютный гавнакодик» может работать быстрее, чем код внутри базы.
Немного забавно, но я про скорость работы ничего не говорил и тем более об ORM. Задача СУБД — хранить данные, но если она как-то где-то умеет хранить спокойно лежащие данные быстрее, ну ладно.
Забавно то, что буква У в слове СУБД как бы намекает, что речь идёт не только о хранении). Чтобы хранить спокойно лежащие данные достаточно регулярных файлов на файловой системе.
О нет, ведь скорость работы, которая отличается на десятки милисекунд это же самое главное!
Ни качество разработки, ни скалируемость, ни выразительность, ни удобство, ни стабильность — а именно скорость.

Ага.
Как по мне, так язык ADA достаточно выразителен и удобен. Стабильность и скалируемость база даёт из коробки. Вообще всё дело просто в объёме данных, с которыми требуется что-то сделать за один логический блок бизнес процесса. И конечно это не про миллисекунды. Как только объём данных логического блока становится каким-то заметным, бороться приходится за эффективность и попытки сделать это сторонним кодом не выдерживают испытаний жизнью.
На небольшом проекте работать быстрее возможно не будет. Но если приложение рассчитанно на горизонтальное масштабирование, то его его легче произвести с логикой в приложении, чем масштабировать транзакции БД.
половина статьи о консистентности данных и половина о том что не надо хранить архив в базе, но если архив не в базе консистентность может пропасть и где потом искать счёт не понятно, из хороших решений только иметь продакшен базу и точно такую же для архива, и данные переодически переносить из одной в другую, тоесть все истории изменений и продакшен базе создаються, но переодически чистяться, база будет большой, но это же архив туда не так часто лезут, зато всегда можно быть уверенным что данные легко найдуться
Вы не могли бы несколько развернуть свою мысль? Как-то у вас не вполне понятно получилось.
если по поводу архивации то перенос данных в другое место и проверка что ничего не потерялось наверно самое сложное особенно если структура архива совершенно другая и мне кажется что будет намного проще если архив и база с текущими данными будут иметь одну и туже структуру, основные таблицы + аудит таблицы, все изменения данных хранятся в рабочей базе также как и в архивной и переодически самые старые потираются освобождая место и кладуться в архивную, будет получаться что в архиве все данные из рабочей базы на момент архивации + предыдущие изменения, архивная база конечно будет огромной, но зато ничё не пропадёт, остаётся вопрос что делать если структура данных меняется, но тут видимо ничего не поделаешь ничего не удалять/переименовывать, а только добавлять новое
Если я все правильно уловил в вашем посте, то, боюсь, вы меня не вполне поняли.

Тот случай, когда читаешь и думаешь: "Это должен был написать я!" :)

Sign up to leave a comment.