Vasilii Gorokhov-Apelsinov

Data-Driven подход для упрощения кода

Sat, 16 Aug 2025 00:00:00 -0400

* Из-за ограничения по времени выступления количество информации ограничено * Из-за сокращённого времени подготовки не все вопросы проработаны достаточно глубоко. Должны быть некоторые пересечения с презентацией Моделирование БД, которые никак не развиты

Моделирование БД

Thu, 26 Mar 2020 00:00:00 -0400

Это было не обучение per se, а скорее организованная дискуссия. Поэтому некоторые слайды сохранили черновые артефакты, а в некоторых случаях представлено несколько вариантов на выбор. Достигнутый результат: К сожалению, из-за коронавируса и других ограничений по большинству поставленных вопросов прийти к консенсусам не удалось

Git & CI для БД и не только

Tue, 30 Jul 2019 00:00:00 -0400

Достигнутый результат: до моего ухода из ЦБ большинство идей так и не было реализовано и осталось только на бумаге Оглядываясь назад: Попытка отслеживать версии enterprise-продукта как коробочного (и выбирать для разных сред разные версии) — всё ещё привлекательна. Однако, она требует нормального разделения на разработку и эксплуатацию. В ЦБ такое разделение было только формальное. С другой стороны, предельный вариант DevOps как раз и означает объединение команд и ответственности. Так что тут у меня не сформировалось готового мнения. Проблема на самом деле более глубокая — в определении, какие именно услуги оказываются заказчику (ITSM), и что именно является АС (ГОСТ 34). В данном случае большое количество новых разработок — это не какие-то опциональные фичи, а регламентированная отчётность, которая должна быть разработана и установлена к определённой дате. А в таком случае сопровождение скорее входит в услугу, и АС возможно являются все среды вместе. Это конечно не исключает управления версиями модулей как отдельных продуктов, однако его полезность остаётся под вопросом. Долгое время у меня существовало убеждение, что CI/CD и ITIL (управление изменениями) в принципе невозможно поженить. Но вроде бы вариант CD в варианте Continuous Delivery (в Prod только вручную по кнопке) рабочий.

Зачем мы используем SQL в отчётах???

Fri, 19 Oct 2018 00:00:00 -0400

В IBM Cognos BI между БД и отчётом есть набор промежуточных слоёв — модель данных. Тем не менее, разработчики регулярно игнорировали её возможности и вставляли SQL-запросы непосредственно в отчёты. Это была небольшая речь, призванная пресечь данную практику. Слайды были оформлены в виде короткого видео (как современные сториз). Достигнутый результат: SQL в отчётах был запрещён (с парой исключений). При проверке отчётов перед релизом — проверяется в т.ч. отсутствие SQL-запросов. Оглядываясь назад: Использование SQL является симптомом, что в данном случае Cognos является неподходящим BI-инструментом, а промежуточная модель не требуется. Степень связанности данных между отчётами практически нулевая, и модель не решает никаких реальных проблем, а только усложняет архитектуру и требует дополнительных ресурсов и времени на разработку и поддержку. Логическая модель начинает быть нужна, когда появляется какая-то единая система показателей, сквозных метрик и т.п. Следующий уровень зрелости. Чтобы дойти до него, требуется много времени и усилий. А потому, пока этой потребности нет, лучше выбирать более простой BI-инструмент. По моему опыту, аналитика в большинстве организаций до уровня потребности в промежуточной модели вообще никогда не дорастает. Кроме того, та же единая система показателей может быть реализована на уровне витрин, и модель опять получается не нужна. IBM Cognos также позволяет интегрировать между собой данные из нескольких источников (выполнять федеративные запросы). Однако такая обработка (соединения) происходит уже не на источниках (push-down), а на сервере Cognos. BI-сервер это не СУБД и не полноценный SQL-движок, и эта доп. обработка существенно замедляет запросы и нагружает сервер. Получается, что эту функциональность можно использовать только на небольших объёмах. На которых модель не особо и требуется, можно обойтись чистым SQL. А уже при средних объёмах надо делать полноценную интеграцию данных на уровне БД, строить хранилище, и модель опять становится не нужна. В данном случае наличие модели было требованием заказчика. Заказчик преследовал две цели: 1) Строить отчёты самостоятельно — но фактически практически не строил 2) Искать показатели по бизнес-названиям — но для выполнения этой функции правильнее было бы реализовать каталог данных

Отчетность vs Аналитика

Thu, 27 Jul 2017 00:00:00 -0400

Основная идея: отчётность и аналитика должны строиться однообразно Оглядываясь назад: идея всё ещё актуальна, а реализованный подход — битемпоральные таблицы и возможность подвинуть одну из дат, чтобы переключаться между отчётностью и аналитикой — считаю изящным и целевым