Обновить
Digital Q.DataBase 18 - SSRS
Digital Q.DataBase 18 - SSRS

🔹 Всем привет. Сегодня хочу рассказать Вам о том, как мы склонировали у себя один из самых "прикладных" сервисов из поставки Microsoft SQL Server.

➡️ Речь пойдет об SQL Server Reporting Services (SSRS) - механизме, который позволяет получать разнообразные отчеты, запрашивая их построение по API или по расписанию.

➡️ Представьте ситуацию: Вы использовали Microsoft SQL Server и у Вас было несколько сотен разнообразных отчетов, что ранее строились на основе данных в Ваших БД. И тут импортозамещение! Надо переходить на российское решение из Реестра Минцифры.
Для замены СУБД самый легкий вариант такого перехода - Digital Q.DataBase. Мастер переноса БД поможет перенести данные, Мастер сравнения БД проверит корректность переноса, Digital Q.CDC обеспечит синхронизацию данных в обеих СУБД, что позволит сократить до нескольких минут сам момент перехода.
Но что делать с сотнями отчётов, что привыкли получать Ваши пользователи?

Оставить как есть, пусть строятся при помощи зарубежного инструмента?
Вряд-ли это приемлемо. Какое-то очень кусочное импортозамещение получается!

Переписать на другом инструменте? Даже из расчета по дню на отчёт это сотни человеко-дней "ручного труда", а потом тестирование, выгребание ошибок, восстановление порушенных интеграций (построение некоторых отчетов могло запрашиваться извне, через API). Тоже так себе вариант!

➡️ Мы предлагаем более живую альтернативу: воспользоваться нашей реинкарнацией службы отчетов. 

На приложенных скриншотах два отчёта. Один построен в оригинальном инструменте, второй у нас. Как видите, они очень похожи, более того построены по одному и тому же шаблону, что был перенесен из оригинала к нам при замене СУБД.

Внешний вид и API - все сохранено. Как говорят наши "заокеанские партнеры" - настоящий "drop-in replacement" (безшовная замена одного инструмента другим).
Именно так и должно выглядеть хорошо проработанное импортозамещение.

Благодарю за внимание к этому посту!

📎 Полезные ссылки
🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase
🔹 Канал в MAX: https://max.ru/join/orlthIssLJbjj37mjlEEYARWFyuJk5yMixLlGPISIzc

Теги:
Всего голосов 7: ↑6 и ↓1+5
Комментарии0

Я перестал пользоваться самыми умными ИИ‑моделями. Программировать стало быстрее и дешевле

В отпуске есть время подумать и исследовать. Я натолкнулся на несколько вещей и открытий для себя. Оказалось, что мне как программисту перестали быть нужны самые умные и дорогие ИИ‑модели. Оказывается, есть такой параметр «Cost per Task», и по этому параметру на первое место вырвалась модель GPT-5.6 Luna (max).

При этом, если вы пользуетесь Codex, она самая тупая в списке моделей. Artificial Analysis Intelligence Index у нее всего 38. Для сравнения, у самой умной GPT-6 Astra (max) этот индекс равен 53. В итоге цена выполненной Luna задачи составляет $0.18 против $3.26 у Astra. Разница почти в 20 раз.

Как я понимаю, бенчмарк «Cost per Task» высчитывается так: когда ставится нормальная, грамотно описанная задача, замеряется, сколько токенов было потрачено на ее выполнение. То есть не в формате «из ХЗ сделаю ТЗ», а в формате, когда в хорошо заданном вопросе уже содержится половина ответа.

Я сначала не поверил, что так и есть, и стал работать, используя самую тупую модель Luna в линейке. И знаете, какие меня ожидали результаты?

Я перестал пользоваться самыми умными ИИ‑моделями. Программировать стало быстрее и дешевле

Публикации