Человек без ученой степени, который построил первую СУБД и получил за это Премию Тьюринга
В начале 1960‑х инженер Чарльз Бахман работал в General Electric и столкнулся с проблемой: данные хранились хаотично, каждый раз приходилось писать новый код для доступа к ним. Его решение — Integrated Data Store (IDS) — стало первой в мире успешной системой управления базами данных, которая позволяла связывать записи и управлять ими без переписывания программ.
Прошло чуть больше десятилетия, и в 1973 году Бахману вручили Премию Тьюринга — высшую награду в компьютерных науках. Событие было настоящей сенсацией, так как он стал первым лауреатом этой премии без PhD и без академического бэкграунда. Инженер-механик по образованию, чистый практик, который просто решал реальные задачи для компании, в которой он работал.
Но на этом история не заканчивается. В 1974 году на легендарной "Великой дискуссии" он на равных спорил с самим Эдгаром Коддом — отцом реляционной модели данных. Бахман отстаивал сетевой подход, Кодд — реляционный. Их спор не был враждой: они признавали заслуги друг друга, а сам Кодд называл IDS «первой настоящей системой баз данных». Эта полемика двигала вперёд всю индустрию.
Итог: человек без учёной степени изменил мир данных, а потом встал в один ряд с величайшими теоретиками. Иногда достаточно просто делать своё дело хорошо!
В начале 1960‑х инженер Чарльз Бахман работал в General Electric и столкнулся с проблемой: данные хранились хаотично, каждый раз приходилось писать новый код для доступа к ним. Его решение — Integrated Data Store (IDS) — стало первой в мире успешной системой управления базами данных, которая позволяла связывать записи и управлять ими без переписывания программ.
Прошло чуть больше десятилетия, и в 1973 году Бахману вручили Премию Тьюринга — высшую награду в компьютерных науках. Событие было настоящей сенсацией, так как он стал первым лауреатом этой премии без PhD и без академического бэкграунда. Инженер-механик по образованию, чистый практик, который просто решал реальные задачи для компании, в которой он работал.
Но на этом история не заканчивается. В 1974 году на легендарной "Великой дискуссии" он на равных спорил с самим Эдгаром Коддом — отцом реляционной модели данных. Бахман отстаивал сетевой подход, Кодд — реляционный. Их спор не был враждой: они признавали заслуги друг друга, а сам Кодд называл IDS «первой настоящей системой баз данных». Эта полемика двигала вперёд всю индустрию.
Итог: человек без учёной степени изменил мир данных, а потом встал в один ряд с величайшими теоретиками. Иногда достаточно просто делать своё дело хорошо!
Когда твоя база данных становится умнее тебя или как ИИ проникает внутрь современных СУБД
Раньше ИИ и база данных жили раздельно: данные хранились в СУБД, а модели крутились где-то рядом. Теперь стена рушится — искусственный интеллект переезжает прямо внутрь СУБД. Вот что происходит прямо сейчас.
1. СУБД помогает настраивать себя сама
Раньше DBA вручную правил индексы и переписывал медленные запросы. Теперь это берёт на себя ИИ.
В SQL Server 2025 механизм Query Intelligence анализирует шаблоны запросов и рекомендует изменения индексов или переписывание запросов с учётом контекста.
2. SQL можно генерировать на естественном языке
Расширение для PostgreSQL pg_ai_query позволяет сделать так:
Поддерживаются OpenAI, Anthropic и Google Gemini.
Oracle Select AI через пакет DBMS_CLOUD_AI делает то же самое: передаёт в LLM промпт с метаданными схемы и возвращает готовый SQL.
Microsoft добавила GitHub Copilot в SSMS 22 — помогает писать, оптимизировать и отлаживать T-SQL.
3. Векторный поиск — новая суперсила СУБД
Раньше для семантического поиска (по смыслу, а не по слову) нужна была отдельная векторная база. Теперь — нет.
SQL Server 2025 ввёл тип VECTOR и индекс DiskANN для быстрого поиска по сходству. Функция VECTOR_DISTANCE считает расстояние через косинусную меру или евклидово расстояние.
PostgreSQL с расширением pgvector — классика для RAG-приложений.
OceanBase в ноябре 2025 открыл под Apache 2.0 AI-базу seekdb с гибридным поиском — одновременно по векторам, полнотекстовым запросам, скалярным полям и пространственным данным.
4. AI-агенты работают с Вашими данными
Oracle AI Database 26ai может использоваться как источник векторных данных для OCI Generative AI Agents. База данных становится бэкендом для агентов, которые принимают решения на основе данных — без выноса информации во внешние системы.
Итог: ИИ внутри СУБД — это реальность для 2026 года. Базы данных становятся самонастраивающимися, разговаривающими (понимают естественный язык), всеядными (скалярные и полнотекстовые данные, графика и мультимедиа, графы, векторы, JSON, геоданные) и агентными.
А главное — мы по-прежнему пишем SELECT. Просто теперь он может значить гораздо больше.
Как Вы думаете, ИИ-агент когда-нибудь заменит DBA полностью? Или это всё равно потребует человеческого контроля? Будем рады обменяться мнениями в комментариях 👇
Раньше ИИ и база данных жили раздельно: данные хранились в СУБД, а модели крутились где-то рядом. Теперь стена рушится — искусственный интеллект переезжает прямо внутрь СУБД. Вот что происходит прямо сейчас.
1. СУБД помогает настраивать себя сама
Раньше DBA вручную правил индексы и переписывал медленные запросы. Теперь это берёт на себя ИИ.
В SQL Server 2025 механизм Query Intelligence анализирует шаблоны запросов и рекомендует изменения индексов или переписывание запросов с учётом контекста.
2. SQL можно генерировать на естественном языке
Расширение для PostgreSQL pg_ai_query позволяет сделать так:
SELECT generate_query('Дай список клиентов, которые ничего не заказывали за последние 3 месяца');Поддерживаются OpenAI, Anthropic и Google Gemini.
Oracle Select AI через пакет DBMS_CLOUD_AI делает то же самое: передаёт в LLM промпт с метаданными схемы и возвращает готовый SQL.
Microsoft добавила GitHub Copilot в SSMS 22 — помогает писать, оптимизировать и отлаживать T-SQL.
3. Векторный поиск — новая суперсила СУБД
Раньше для семантического поиска (по смыслу, а не по слову) нужна была отдельная векторная база. Теперь — нет.
SQL Server 2025 ввёл тип VECTOR и индекс DiskANN для быстрого поиска по сходству. Функция VECTOR_DISTANCE считает расстояние через косинусную меру или евклидово расстояние.
PostgreSQL с расширением pgvector — классика для RAG-приложений.
OceanBase в ноябре 2025 открыл под Apache 2.0 AI-базу seekdb с гибридным поиском — одновременно по векторам, полнотекстовым запросам, скалярным полям и пространственным данным.
4. AI-агенты работают с Вашими данными
Oracle AI Database 26ai может использоваться как источник векторных данных для OCI Generative AI Agents. База данных становится бэкендом для агентов, которые принимают решения на основе данных — без выноса информации во внешние системы.
Итог: ИИ внутри СУБД — это реальность для 2026 года. Базы данных становятся самонастраивающимися, разговаривающими (понимают естественный язык), всеядными (скалярные и полнотекстовые данные, графика и мультимедиа, графы, векторы, JSON, геоданные) и агентными.
А главное — мы по-прежнему пишем SELECT. Просто теперь он может значить гораздо больше.
Как Вы думаете, ИИ-агент когда-нибудь заменит DBA полностью? Или это всё равно потребует человеческого контроля? Будем рады обменяться мнениями в комментариях 👇
Media is too big
VIEW IN TELEGRAM
В этом коротком видео я демонстрирую, как Digital Q.DataBase 18.2 исполняет нативный T-SQL скрипт через DBeaver, а также как те же объекты доступны из Python через библиотеку pymssql по протоколу TDS.
► В примере используются GO, SET DATEFORMAT, OBJECT_ID, sys.objects, INFORMATION_SCHEMA, вычисляемые столбцы, хранимые процедуры GetSalesReport и CalculateManagerBonus, а также их вызов из Python с обработкой нескольких наборов результатов.
Видео также доступно на:
VK
RuTube
Dzen
YouTube
➡️ Подпишись на МАХ канал!
#СУБД #TSQL #MSSQL #SQLServer #Импортозамещение
► В примере используются GO, SET DATEFORMAT, OBJECT_ID, sys.objects, INFORMATION_SCHEMA, вычисляемые столбцы, хранимые процедуры GetSalesReport и CalculateManagerBonus, а также их вызов из Python с обработкой нескольких наборов результатов.
Видео также доступно на:
VK
RuTube
Dzen
YouTube
#СУБД #TSQL #MSSQL #SQLServer #Импортозамещение
Please open Telegram to view this post
VIEW IN TELEGRAM
Дорогие подписчики!
📚 С Днём знаний!
Поздравляем Всех, кто учит и учится — студентов, преподавателей, школьников и их родителей.
Пусть этот год будет интересным, продуктивным и полным открытий.
А для тех, кто преподаёт IT-дисциплины, у нас есть хорошая новость: мы подготовили учебный курс по СУБД на два семестра.
В нём лекционный курс и 18 практических занятий — от проектирования баз данных до работы с in-memory и векторным поиском.
Материалы уже используются ВУЗах, и мы готовы делиться ими с преподавателями.
Если хотите использовать наш курс в своём учебном процессе — напишите нам, и мы предоставим ссылку на скачивание.
🔗 supportqdb@diasoft.ru
С праздником!🎓
Поздравляем Всех, кто учит и учится — студентов, преподавателей, школьников и их родителей.
Пусть этот год будет интересным, продуктивным и полным открытий.
А для тех, кто преподаёт IT-дисциплины, у нас есть хорошая новость: мы подготовили учебный курс по СУБД на два семестра.
В нём лекционный курс и 18 практических занятий — от проектирования баз данных до работы с in-memory и векторным поиском.
Материалы уже используются ВУЗах, и мы готовы делиться ими с преподавателями.
Если хотите использовать наш курс в своём учебном процессе — напишите нам, и мы предоставим ссылку на скачивание.
С праздником!
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
В этом коротком видео я демонстрирую работу модуля Onyx в Digital Q.DataBase и выполнение PL/SQL-скриптов, написанных для Oracle Database.
► В основном примере (через qclient) выполняется полноценный PL/SQL-сценарий: создаётся таблица, объявляются PACKAGE и PACKAGE BODY с процедурами, используется отдельная функция и анонимный PL/SQL-блок.
В скрипте используются характерные для Oracle механизмы: NUMBER, VARCHAR2, CLOB, SYSDATE, DUAL, ADD_MONTHS, а также пакеты DBMS_LOB и DBMS_OUTPUT. Скрипт компилируется и выполняется непосредственно в модуле Onyx.
► Также показываю, что работать с Onyx можно привычным способом через DBeaver.
Подключаемся к Digital Q.DataBase по характерному для Oracle порту 1521 и прямо из SQL-редактора выполняем обычный PL/SQL-скрипт: создаём таблицу employees_1, хранимую процедуру add_employee_1, вызываем её через CALL и проверяем результат обычным SELECT.
То есть для разработчика работа выглядит привычно: DBeaver, PL/SQL, процедуры, Oracle-типы и Oracle-синтаксис - но исполняется всё в Digital Q.DataBase Onyx.
Это позволяет переносить существующие Oracle-приложения и PL/SQL-код с минимальным объёмом изменений.
Видео также доступно на:
VK
RuTube
Dzen
YouTube
➡️ Подпишись на МАХ канал!
#СУБД #TSQL #Oracle #OracleDataBase #Импортозамещение
► В основном примере (через qclient) выполняется полноценный PL/SQL-сценарий: создаётся таблица, объявляются PACKAGE и PACKAGE BODY с процедурами, используется отдельная функция и анонимный PL/SQL-блок.
В скрипте используются характерные для Oracle механизмы: NUMBER, VARCHAR2, CLOB, SYSDATE, DUAL, ADD_MONTHS, а также пакеты DBMS_LOB и DBMS_OUTPUT. Скрипт компилируется и выполняется непосредственно в модуле Onyx.
► Также показываю, что работать с Onyx можно привычным способом через DBeaver.
Подключаемся к Digital Q.DataBase по характерному для Oracle порту 1521 и прямо из SQL-редактора выполняем обычный PL/SQL-скрипт: создаём таблицу employees_1, хранимую процедуру add_employee_1, вызываем её через CALL и проверяем результат обычным SELECT.
То есть для разработчика работа выглядит привычно: DBeaver, PL/SQL, процедуры, Oracle-типы и Oracle-синтаксис - но исполняется всё в Digital Q.DataBase Onyx.
Это позволяет переносить существующие Oracle-приложения и PL/SQL-код с минимальным объёмом изменений.
Видео также доступно на:
VK
RuTube
Dzen
YouTube
#СУБД #TSQL #Oracle #OracleDataBase #Импортозамещение
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Ассоциация Разработчиков СУБД RuDB
Готовим к выпуску новую версию RuDB 26.09
Новая версия RuDB 26.09 уже собрана под все поддерживаемые операционные системы и сейчас проходит финальные испытания перед выпуском.
RuDB 26.09 станет последней версией на базе ядра PostgreSQL 18. Следующая версия RuDB будет построена уже на PostgreSQL 19.
Таким образом, выпуск 26.09 завершит этап развития RuDB на 18-м ядре и станет точкой перехода к следующему поколению платформы.
Релиз уже близко. Следите за обновлениями!
#RuDB #PostgreSQL #СУБД #БазыДанных #SQL #РоссийскоеПО
Новая версия RuDB 26.09 уже собрана под все поддерживаемые операционные системы и сейчас проходит финальные испытания перед выпуском.
RuDB 26.09 станет последней версией на базе ядра PostgreSQL 18. Следующая версия RuDB будет построена уже на PostgreSQL 19.
Таким образом, выпуск 26.09 завершит этап развития RuDB на 18-м ядре и станет точкой перехода к следующему поколению платформы.
Релиз уже близко. Следите за обновлениями!
#RuDB #PostgreSQL #СУБД #БазыДанных #SQL #РоссийскоеПО
Media is too big
VIEW IN TELEGRAM
В этом видео показываю работу службы отчётности Digital Q.DataBase и поддержку RDL (Report Definition Language) — формата описания отчётов, используемого в Microsoft SQL Server Reporting Services (SSRS).
► При миграции с Microsoft SQL Server одной из сложных задач становится сохранение существующей отчётности.
В корпоративных системах могут годами накапливаться сотни и тысячи RDL-отчётов, а их перенос на другой стек способен превратиться в отдельный большой проект.
В Digital Q.DataBase реализована совместимость с RDL и привычными механизмами SSRS, чтобы существующие отчёты и интеграции можно было переносить с минимальными изменениями.
Видео также доступно на:
VK
RuTube
Dzen
YouTube
► При миграции с Microsoft SQL Server одной из сложных задач становится сохранение существующей отчётности.
В корпоративных системах могут годами накапливаться сотни и тысячи RDL-отчётов, а их перенос на другой стек способен превратиться в отдельный большой проект.
В Digital Q.DataBase реализована совместимость с RDL и привычными механизмами SSRS, чтобы существующие отчёты и интеграции можно было переносить с минимальными изменениями.
Видео также доступно на:
VK
RuTube
Dzen
YouTube
SELECT DISTINCT ON: недооценённая возможность PostgreSQL
В арсенале PostgreSQL есть множество синтаксических конструкций, которые разработчики знают «в лицо», но редко используют по-настоящему. Одна из них — SELECT DISTINCT ON.
Большинство из нас привыкли к классическому DISTINCT: он убирает полные дубликаты строк. А вот расширение DISTINCT ON используется сильно реже. И напрасно!
DISTINCT ON позволяет оставить только первую строку из каждой группы записей, сгруппированных по указанному полю (или набору полей). При этом возвращается целая строка, а не агрегированное значение, как в GROUP BY.
Классический пример — для каждого клиента получить его самый последний заказ. Без DISTINCT ON пришлось бы использовать оконную функцию или самосоединение. С ним — запрос лаконичен и легко читаем:
Что здесь происходит:
DISTINCT ON (customer_id) — говорит СУБД оставить по одной строке на каждого уникального клиента.
ORDER BY определяет, какая именно строка из группы будет выбрана. В примере — самая поздняя (по убыванию created_at).
Важное ограничение, о котором часто забывают: первый столбец (или несколько) в ORDER BY обязан совпадать с полями, указанными в DISTINCT ON. Иначе PostgreSQL не сможет однозначно определить порядок внутри группы, и результат может оказаться недетерминированным. Это не ошибка проектирования, а строгое требование логики: СУБД должна знать, по какому критерию выбирать «первую» строку.
Если в Ваших запросах встречаются задачи типа «самый последний», «самый ранний» или «на максимальную сумму» в разрезе некоторого объекта — присмотритесь к DISTINCT ON. Вы удивитесь, как часто он оказывается именно тем, что нужно, и как редко о нём вспоминают.
Попробуйте в следующий раз — и, возможно, он займёт почётное место в вашем SQL-арсенале. 🐘
В арсенале PostgreSQL есть множество синтаксических конструкций, которые разработчики знают «в лицо», но редко используют по-настоящему. Одна из них — SELECT DISTINCT ON.
Большинство из нас привыкли к классическому DISTINCT: он убирает полные дубликаты строк. А вот расширение DISTINCT ON используется сильно реже. И напрасно!
DISTINCT ON позволяет оставить только первую строку из каждой группы записей, сгруппированных по указанному полю (или набору полей). При этом возвращается целая строка, а не агрегированное значение, как в GROUP BY.
Классический пример — для каждого клиента получить его самый последний заказ. Без DISTINCT ON пришлось бы использовать оконную функцию или самосоединение. С ним — запрос лаконичен и легко читаем:
SELECT DISTINCT ON (customer_id)
id, customer_id, total_amount, created_at
FROM orders
ORDER BY customer_id, created_at DESC;
Что здесь происходит:
DISTINCT ON (customer_id) — говорит СУБД оставить по одной строке на каждого уникального клиента.
ORDER BY определяет, какая именно строка из группы будет выбрана. В примере — самая поздняя (по убыванию created_at).
Важное ограничение, о котором часто забывают: первый столбец (или несколько) в ORDER BY обязан совпадать с полями, указанными в DISTINCT ON. Иначе PostgreSQL не сможет однозначно определить порядок внутри группы, и результат может оказаться недетерминированным. Это не ошибка проектирования, а строгое требование логики: СУБД должна знать, по какому критерию выбирать «первую» строку.
Если в Ваших запросах встречаются задачи типа «самый последний», «самый ранний» или «на максимальную сумму» в разрезе некоторого объекта — присмотритесь к DISTINCT ON. Вы удивитесь, как часто он оказывается именно тем, что нужно, и как редко о нём вспоминают.
Попробуйте в следующий раз — и, возможно, он займёт почётное место в вашем SQL-арсенале. 🐘
СУБД и терабайты мусора. История о том, как "PostgreSQL полетел на Марс"
В одном консалтинговом проекте синхронизация двух серверов БД в легаси-приложении порождала несколько терабайт временных данных в день — при том, что сама БД занимала менее 50 ГБ.
Решение нашлось в двунаправленной логической репликации (bidirectional replication), которая стала возможна благодаря улучшению механизма логической репликации в PostgreSQL, которая впервые появилась в 16 версии этой СУБД. Она позволяет двум экземплярам работать в режиме «активный-активный», синхронизируясь без лавинообразного роста служебных данных. Механизм избавляет от лишних циклов и радикально сокращает накладные расходы.
Эту технику инженер Percona Фернандо Лаударес Камаргос впервые представил на Postgres Conference: Seattle 2024. Но вместо сухих цифр он проиллюстрировал её… космическим круизом на Марс.
Представьте: лайнер с автономной БД под управлением PostgreSQL на борту, связь с Землёй ненадёжна, а данные нужно синхронизировать при редких сеансах. Именно для такого сценария двунаправленная репликация — идеальный спасательный круг.
Конечно, в реальности мы с Вами не управляем космическими кораблями. Но если Ваш проект не летит к Марсу, а просто синхронизирует два дата-центра по ненадежному или медленному каналу связи, то этот механизм PostgreSQL сэкономит вам не терабайты, а нервы. 😉
В одном консалтинговом проекте синхронизация двух серверов БД в легаси-приложении порождала несколько терабайт временных данных в день — при том, что сама БД занимала менее 50 ГБ.
Решение нашлось в двунаправленной логической репликации (bidirectional replication), которая стала возможна благодаря улучшению механизма логической репликации в PostgreSQL, которая впервые появилась в 16 версии этой СУБД. Она позволяет двум экземплярам работать в режиме «активный-активный», синхронизируясь без лавинообразного роста служебных данных. Механизм избавляет от лишних циклов и радикально сокращает накладные расходы.
Эту технику инженер Percona Фернандо Лаударес Камаргос впервые представил на Postgres Conference: Seattle 2024. Но вместо сухих цифр он проиллюстрировал её… космическим круизом на Марс.
Представьте: лайнер с автономной БД под управлением PostgreSQL на борту, связь с Землёй ненадёжна, а данные нужно синхронизировать при редких сеансах. Именно для такого сценария двунаправленная репликация — идеальный спасательный круг.
Конечно, в реальности мы с Вами не управляем космическими кораблями. Но если Ваш проект не летит к Марсу, а просто синхронизирует два дата-центра по ненадежному или медленному каналу связи, то этот механизм PostgreSQL сэкономит вам не терабайты, а нервы. 😉
Приглашаем Вас на наш День СУБД — уже второй по счёту.
☀️ 27 октября, 14:00–23:00 (МСК)
🤖 Москва, Кибердом (м. «Улица 1905 года», 2-я Звенигородская улица, 12с18)
🗣 Вход бесплатный, формат — офлайн, без трансляции.
Регистрация по ссылке: https://dbd.diasoft.ru/
Что в программе:
· живые демонстрации миграции с MS SQL и Oracle без переписывания кода;
· выступления клиентов, которые уже прошли переход;
· встречи с командой разработки Digital Q.DataBase;
· методики и чек-листы, которые можно сразу применить в своей работе.
Больше интересного в нашем канале мероприятия, где мы делимся материалами, видео и фотографиями с прошлого Дня СУБД (который прошел в апреле 2026) и раскрываем программу будующего осеннего события!
🪄 Telegram
⭐️ MAX
Подписывайтесь, чтобы быть в курсе. До встречи в Кибердоме!
Регистрация по ссылке: https://dbd.diasoft.ru/
Что в программе:
· живые демонстрации миграции с MS SQL и Oracle без переписывания кода;
· выступления клиентов, которые уже прошли переход;
· встречи с командой разработки Digital Q.DataBase;
· методики и чек-листы, которые можно сразу применить в своей работе.
Больше интересного в нашем канале мероприятия, где мы делимся материалами, видео и фотографиями с прошлого Дня СУБД (который прошел в апреле 2026) и раскрываем программу будующего осеннего события!
Подписывайтесь, чтобы быть в курсе. До встречи в Кибердоме!
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
В этом видео показываю Digital Q.CDC (Change Data Capture) - инструмент для захвата и передачи изменений между СУБД.
Разберём, как CDC позволяет переносить данные без длительного простоя: пока пользователи продолжают работать с исходной системой, изменения фиксируются и передаются в целевую базу.
Такой подход позволяет вынести основную работу за пределы окна переключения и существенно сократить время финальной миграции.
► Основные сценарии использования Digital Q.CDC:
🔹 миграция промышленных баз данных с минимальным окном переключения;
🔹 поддержание актуальной копии данных на резервной площадке;
🔹 передача изменений из транзакционной СУБД в аналитические системы и хранилища;
🔹 консолидация данных из нескольких распределённых систем в единой базе.
Отдельно показываю новый веб-интерфейс Digital Q.CDC.
Через браузер можно создавать и настраивать задачи репликации, контролировать их состояние, просматривать статистику и графики, управлять запуском и остановкой процессов, работать с журналом аудита и уведомлениями.
Digital Q.CDC поддерживает двустороннюю репликацию между Digital Q.DataBase и Oracle Database, PostgreSQL и Microsoft SQL Server.
В видео также показываю настройку репликации СУБД Digital Q.DataBase → Oracle, мониторинг обработки изменений, журнал работы, аудит, SMTP-уведомления и разграничение доступа пользователей по ролям.
Видео также доступно на:
VK
RuTube
Dzen
YouTube
#DigitalQCDC #CDC #ChangeDataCapture #СУБД #МиграцияДанных
Разберём, как CDC позволяет переносить данные без длительного простоя: пока пользователи продолжают работать с исходной системой, изменения фиксируются и передаются в целевую базу.
Такой подход позволяет вынести основную работу за пределы окна переключения и существенно сократить время финальной миграции.
► Основные сценарии использования Digital Q.CDC:
🔹 миграция промышленных баз данных с минимальным окном переключения;
🔹 поддержание актуальной копии данных на резервной площадке;
🔹 передача изменений из транзакционной СУБД в аналитические системы и хранилища;
🔹 консолидация данных из нескольких распределённых систем в единой базе.
Отдельно показываю новый веб-интерфейс Digital Q.CDC.
Через браузер можно создавать и настраивать задачи репликации, контролировать их состояние, просматривать статистику и графики, управлять запуском и остановкой процессов, работать с журналом аудита и уведомлениями.
Digital Q.CDC поддерживает двустороннюю репликацию между Digital Q.DataBase и Oracle Database, PostgreSQL и Microsoft SQL Server.
В видео также показываю настройку репликации СУБД Digital Q.DataBase → Oracle, мониторинг обработки изменений, журнал работы, аудит, SMTP-уведомления и разграничение доступа пользователей по ролям.
Видео также доступно на:
VK
RuTube
Dzen
YouTube
#DigitalQCDC #CDC #ChangeDataCapture #СУБД #МиграцияДанных
Давайте чуть подробнее про DGrid.
Мы привыкли, что СУБД работает с таблицами: строки, столбцы, индексы, SQL-запросы.
Но далеко не для всех задач нужна полноценная реляционная модель.
Иногда нужно просто очень быстро сохранить значение по ключу и так же быстро его получить.
Например, состояние пользовательской сессии, параметр приложения, промежуточный результат расчёта или часто используемое значение.
Для таких задач используется модель key-value, «ключ - значение».
Знаем ключ, сразу получаем связанное с ним значение.
В Digital Q.DataBase эту задачу решает DGrid.
Использовать его можно в двух вариантах.
► Первый - внутреннее KV-хранилище Digital Q.DataBase.
Оно работает отдельным процессом под контролем СУБД, и обращаться к нему можно непосредственно из SQL.
► Второй - DGrid как самостоятельный сервис.
Его можно вынести за пределы конкретного экземпляра СУБД и использовать в распределённой конфигурации с автоматическим перераспределением данных между нодами.
При этом DGrid не ограничивается простым key-value.
Он поддерживает и табличные структуры, а работать с данными можно через SQL-функции, собственный API, а также Redis- и Memcached-совместимые протоколы.
Данные могут храниться на уровне сеанса, пользователя или глобально.
Практические сценарии - хранение Web-сессий, кэширование результатов тяжёлых расчётов и промежуточный кэш между компонентами приложения.
► В составе Digital Q.DataBase DGrid также заменил ранее использовавшийся Tarantool DB.
То есть DGrid не заменяет обычное реляционное хранилище, а дополняет его там, где нужен быстрый доступ к данным и другой способ их хранения.
#СУБД #DGrid #KeyValue #Redis
Мы привыкли, что СУБД работает с таблицами: строки, столбцы, индексы, SQL-запросы.
Но далеко не для всех задач нужна полноценная реляционная модель.
Иногда нужно просто очень быстро сохранить значение по ключу и так же быстро его получить.
Например, состояние пользовательской сессии, параметр приложения, промежуточный результат расчёта или часто используемое значение.
Для таких задач используется модель key-value, «ключ - значение».
Знаем ключ, сразу получаем связанное с ним значение.
В Digital Q.DataBase эту задачу решает DGrid.
Использовать его можно в двух вариантах.
► Первый - внутреннее KV-хранилище Digital Q.DataBase.
Оно работает отдельным процессом под контролем СУБД, и обращаться к нему можно непосредственно из SQL.
► Второй - DGrid как самостоятельный сервис.
Его можно вынести за пределы конкретного экземпляра СУБД и использовать в распределённой конфигурации с автоматическим перераспределением данных между нодами.
При этом DGrid не ограничивается простым key-value.
Он поддерживает и табличные структуры, а работать с данными можно через SQL-функции, собственный API, а также Redis- и Memcached-совместимые протоколы.
Данные могут храниться на уровне сеанса, пользователя или глобально.
Практические сценарии - хранение Web-сессий, кэширование результатов тяжёлых расчётов и промежуточный кэш между компонентами приложения.
► В составе Digital Q.DataBase DGrid также заменил ранее использовавшийся Tarantool DB.
То есть DGrid не заменяет обычное реляционное хранилище, а дополняет его там, где нужен быстрый доступ к данным и другой способ их хранения.
#СУБД #DGrid #KeyValue #Redis
Марафон совместимости СУБД Digital Q.DataBase продолжается...
Его цель обозначил Алексей Татаринов, руководитель Digital Q.DataBase: "Каждое успешное тестирование совместимости СУБД Digital Q.DataBase с решениями других разработчиков расширяет возможности создания импортонезависимых программных комплексов, востребованных организациями из различных сфер для импортозамещения системного ПО"
5 партнеров, 5 отраслей, 1 СУБД. Детали:
1️⃣ Documino от "АйДи – Технологии управления" – один из лидеров российского рынка современных СЭД. Совместимость с Digital Q.DataBase позволяет организациям из любых отраслей выстраивать импортонезависимый и безопасный контур корпоративного документооборота.
2️⃣ SmartWay от PST – платформа для цифровизации сложных бизнес-правил и стратегий принятия решений. Digital Q.DataBase обеспечивает необходимый уровень производительности и надежности для таких систем. Подтверждена готовность решений к совместной промышленной эксплуатации в контурах крупных предприятий, фин.организаций и компаниях госсектора.
3️⃣ Продукты компании "Альта-Софт" широко используются участниками внешнеэкономической деятельности (ВЭД) и таможенными представителями на территории всей России. Для них критична надежность и безопасность работы с данными. Совместимость программного комплекса "Альта-ГТД" с Digital Q.DataBase позволяет предложить участникам ВЭД импортонезависимый программный стек.
4️⃣ Подтверждена корректная и стабильная совместная работа Digital Q.DataBase и телемедицинской платформы "Медтера.Телемедицина" от "Медлайнсофт". Такие платформы работают со сведениями, составляющими врачебную тайну, и специальными категориями персональных данных. Подтвержденная совместимость позволяет мед.организациям выстраивать телемедицинские сервисы на импортонезависимом программном стеке.
5️⃣ Подтвержденная совместимость платформы OpenBPM от Хоулмонт и Digital Q.DataBase позволяет организациям использовать российскую СУБД в составе решений для автоматизации бизнес-процессов и создавать надежную технологическую основу для корпоративных BPM-систем.
Его цель обозначил Алексей Татаринов, руководитель Digital Q.DataBase: "Каждое успешное тестирование совместимости СУБД Digital Q.DataBase с решениями других разработчиков расширяет возможности создания импортонезависимых программных комплексов, востребованных организациями из различных сфер для импортозамещения системного ПО"
5 партнеров, 5 отраслей, 1 СУБД. Детали:
Please open Telegram to view this post
VIEW IN TELEGRAM
Onyx - модуль Digital Q.DataBase, воспроизводящий функциональность Oracle Database.
И это не только поддержка PL/SQL.
В Onyx реализована функциональность системных пакетов DBMS_* и UTL_*, которые используются в Oracle-приложениях.
Несколько интересных примеров:
DBMS_AQ / DBMS_AQADM - очереди сообщений внутри СУБД: отправка, получение и управление очередями.
DBMS_CRYPTO - хеширование, шифрование/расшифрование и MAC.
DBMS_LOCK - пользовательские блокировки для синхронизации процессов.
DBMS_PARALLEL_EXECUTE - разбиение больших операций на части и их параллельное выполнение.
DBMS_PIPE - обмен сообщениями между сессиями через именованные каналы.
DBMS_SCHEDULER - планирование и выполнение фоновых заданий.
DBMS_SQL - расширенная работа с динамическим SQL: курсоры, параметры, выполнение и получение результатов.
И это только часть реализованных Oracle-пакетов.
Digital Q.DataBase: меняем СУБД, а не приложение.
Скоро по каждому из этих пакетов мы выпустим отдельный видеоурок: разберём, для чего он нужен, как работает и покажем его применение на практических примерах в Digital Q.DataBase.
#ЗаменаOracle #OracleDB #Импортозамещение #СУБД
И это не только поддержка PL/SQL.
В Onyx реализована функциональность системных пакетов DBMS_* и UTL_*, которые используются в Oracle-приложениях.
Несколько интересных примеров:
DBMS_AQ / DBMS_AQADM - очереди сообщений внутри СУБД: отправка, получение и управление очередями.
DBMS_CRYPTO - хеширование, шифрование/расшифрование и MAC.
DBMS_LOCK - пользовательские блокировки для синхронизации процессов.
DBMS_PARALLEL_EXECUTE - разбиение больших операций на части и их параллельное выполнение.
DBMS_PIPE - обмен сообщениями между сессиями через именованные каналы.
DBMS_SCHEDULER - планирование и выполнение фоновых заданий.
DBMS_SQL - расширенная работа с динамическим SQL: курсоры, параметры, выполнение и получение результатов.
И это только часть реализованных Oracle-пакетов.
Digital Q.DataBase: меняем СУБД, а не приложение.
Скоро по каждому из этих пакетов мы выпустим отдельный видеоурок: разберём, для чего он нужен, как работает и покажем его применение на практических примерах в Digital Q.DataBase.
#ЗаменаOracle #OracleDB #Импортозамещение #СУБД
🦆 Как утка по имени Уилбур дала название для DuckDB – самой скачиваемой аналитической СУБД в мире
В 2018 году двое амстердамских учёных из CWI (того самого научного центра, где в 1989-м Гвидо ван Россум начал писать Python) — старший научный сотрудник Ханнес Мюлайзен и его аспирант Марк Расвельдт — начали проект без бюджета, роадмапа и заказчика. Они задались вопросом: почему дата-сайентисты мучаются с медленными dataframe-движками вместо нормальной СУБД? И решили написать свою.
Идея проекта формулировалась просто — «нужна легкая СУБД вроде SQLite, но только для аналитики»: встраиваемый движок без сервера и сложной установки, но оптимизированный под аналитические запросы.
Первое демо с результатами проекта они провели в 2019-м на конференции SIGMOD. Именно тогда мир узнал о СУБД DuckDB - названной так в честь утки по имени Уилбур, принадлежавшей Ханнесу.
В 2021-м Ханнес и Марк основали DuckDB Labs. А 2024-м вышла версия 1.0 с кодовым именем Snow Duck. Сегодня DuckDB — одна из самых популярных аналитических СУБД: миллионы загрузок в месяц и десятки тысяч звёзд на GitHub.
История DuckDB — редкий пример того, как исследовательский проект стал востребованным инструментом для крупнейших корпораций, тысяч стартапов и миллионов специалистов по анализу данных. Просто два умных человека заметили реальную боль data-аналитиков и не стали никого ждать: взяли и сами написали инструмент для решения проблемы. Ну а утка по имени Уилбур им в этом помогла.
В 2018 году двое амстердамских учёных из CWI (того самого научного центра, где в 1989-м Гвидо ван Россум начал писать Python) — старший научный сотрудник Ханнес Мюлайзен и его аспирант Марк Расвельдт — начали проект без бюджета, роадмапа и заказчика. Они задались вопросом: почему дата-сайентисты мучаются с медленными dataframe-движками вместо нормальной СУБД? И решили написать свою.
Идея проекта формулировалась просто — «нужна легкая СУБД вроде SQLite, но только для аналитики»: встраиваемый движок без сервера и сложной установки, но оптимизированный под аналитические запросы.
Первое демо с результатами проекта они провели в 2019-м на конференции SIGMOD. Именно тогда мир узнал о СУБД DuckDB - названной так в честь утки по имени Уилбур, принадлежавшей Ханнесу.
В 2021-м Ханнес и Марк основали DuckDB Labs. А 2024-м вышла версия 1.0 с кодовым именем Snow Duck. Сегодня DuckDB — одна из самых популярных аналитических СУБД: миллионы загрузок в месяц и десятки тысяч звёзд на GitHub.
История DuckDB — редкий пример того, как исследовательский проект стал востребованным инструментом для крупнейших корпораций, тысяч стартапов и миллионов специалистов по анализу данных. Просто два умных человека заметили реальную боль data-аналитиков и не стали никого ждать: взяли и сами написали инструмент для решения проблемы. Ну а утка по имени Уилбур им в этом помогла.
С Днём программиста!
Это праздник людей, которые умеют превращать идеи в работающие вещи.
Тех, кто часами смотрит в монитор, чтобы в итоге всё просто работало - и никто не задумывался, сколько за этим стоит...
Мы видим программистов каждый день: они пишут то, что потом живёт в банках, больницах, на транспорте, в магазинах.
Без них любые системы это просто железо.
Спасибо Вам за Вашу работу!
За терпение, за любопытство, за умение не сдаваться, когда что-то не собирается с первого раза.
С праздником!
Пусть будет больше интересных задач, удобных инструментов и решений, которые приятно находить.
Это праздник людей, которые умеют превращать идеи в работающие вещи.
Тех, кто часами смотрит в монитор, чтобы в итоге всё просто работало - и никто не задумывался, сколько за этим стоит...
Мы видим программистов каждый день: они пишут то, что потом живёт в банках, больницах, на транспорте, в магазинах.
Без них любые системы это просто железо.
Спасибо Вам за Вашу работу!
За терпение, за любопытство, за умение не сдаваться, когда что-то не собирается с первого раза.
С праздником!
Пусть будет больше интересных задач, удобных инструментов и решений, которые приятно находить.
Media is too big
VIEW IN TELEGRAM
Как перенести приложение с Oracle Forms в веб, сохранив бизнес-логику и привычное поведение экранных форм?
В видео разбираем технологию автоматизированного переноса на Go и показываем её работу на демонстрационном приложении.
► Рассказываем, почему замены СУБД недостаточно и что усложняет ручной перенос.
Показываем, как из файлов .fmb извлекаются метаданные, SQL и PL/SQL-код, как преобразуются триггеры и как связаны JSON, сервер на Go и браузерный интерфейс.
В представленном решении около 70% работ выполняется автоматически.
Оставшаяся часть — адаптация интерфейса и разработка Go-компонентов для конкретных форм.
В практической части Дмитрий Пшеничный из отдела разработки сравнивает исходное и перенесённое приложения: выполнение SQL-запросов, добавление и обновление записей, вызов хранимых процедур и функций, вывод результатов в интерфейс.
Видео также доступно на (в них есть также и таймкоды):
VK
Dzen
YouTube
#OracleForms #Go #Миграция #БазыДанных #PLSQL
В видео разбираем технологию автоматизированного переноса на Go и показываем её работу на демонстрационном приложении.
► Рассказываем, почему замены СУБД недостаточно и что усложняет ручной перенос.
Показываем, как из файлов .fmb извлекаются метаданные, SQL и PL/SQL-код, как преобразуются триггеры и как связаны JSON, сервер на Go и браузерный интерфейс.
В представленном решении около 70% работ выполняется автоматически.
Оставшаяся часть — адаптация интерфейса и разработка Go-компонентов для конкретных форм.
В практической части Дмитрий Пшеничный из отдела разработки сравнивает исходное и перенесённое приложения: выполнение SQL-запросов, добавление и обновление записей, вызов хранимых процедур и функций, вывод результатов в интерфейс.
Видео также доступно на (в них есть также и таймкоды):
VK
Dzen
YouTube
#OracleForms #Go #Миграция #БазыДанных #PLSQL
Совсем немного осталось до нашего второго Дня СУБД, который пройдёт 27 октября.
Поторопитесь зарегистрироваться на мероприятие!
Вход бесплатный, регистрация по ссылке https://dbd.diasoft.ru/
Мы очень ждём этой встречи и хотим вспомнить, как это было в первый раз.
🐬 21 апреля 2026 года мы провели первый в истории «Диасофт» День СУБД.
Мероприятие посетили более 350 экспертов: представители крупнейших банков, IT-разработчиков и интеграторов, производственных, медицинских, образовательных организаций, ретейлеров и компаний из других отраслей экономики.
На конференции анонсировали бесплатную национальную СУБД RuDB с открытым кодом.
Рассказали о функциональности «Полиглот» Digital Q.DataBase, поддержке диалектов Oracle, MS SQL и PostgreSQL.
Помимо деловой части, гостей ждали фуршет и развлекательная программа, вечер получился очень насыщенным и живым!
️
► Видео с прошлого Дня СУБД:
https://rutube.ru/plst/1623202/
Поторопитесь зарегистрироваться на мероприятие!
Вход бесплатный, регистрация по ссылке https://dbd.diasoft.ru/
Мы очень ждём этой встречи и хотим вспомнить, как это было в первый раз.
Мероприятие посетили более 350 экспертов: представители крупнейших банков, IT-разработчиков и интеграторов, производственных, медицинских, образовательных организаций, ретейлеров и компаний из других отраслей экономики.
На конференции анонсировали бесплатную национальную СУБД RuDB с открытым кодом.
Рассказали о функциональности «Полиглот» Digital Q.DataBase, поддержке диалектов Oracle, MS SQL и PostgreSQL.
Помимо деловой части, гостей ждали фуршет и развлекательная программа, вечер получился очень насыщенным и живым!
️
► Видео с прошлого Дня СУБД:
https://rutube.ru/plst/1623202/
Please open Telegram to view this post
VIEW IN TELEGRAM
От Oracle к Digital Q.DataBase — с привычными приложениями
В предыдущем посте мы рассказали о поддержке диалекта Oracle — PL/SQL.
Продолжим тему: что происходит с приложениями, которые подключаются к базе?
Мы создали библиотеку, которая эмулирует Oracle Instant Client.
Она позволяет переключать приложения с Oracle на Q.DataBase без перекомпиляции и изменений в коде.
Для приложений, использующих поддерживаемые функции «толстого» клиента, переход сводится к замене клиентской библиотеки и настройке подключения.
Приложение продолжает работать через привычный интерфейс.
Есть и другой вариант — подключение через наш JDBC-драйвер.
При этом на стороне Q.DataBase по-прежнему могут выполняться PL/SQL-конструкции.
Можно работать в любимом DBeaver, не замечая разницы и сохраняя привычный подход к работе с базой.
Драйверы скоро будут доступны для скачивания на нашем сайте, а пока выдаём их по запросу.
Достаточно оставить комментарий под постом, написать в личные сообщения или на почту supportqdb@diasoft.ru.
#Oracle #Импортозамещение #JDBC #qdb
В предыдущем посте мы рассказали о поддержке диалекта Oracle — PL/SQL.
Продолжим тему: что происходит с приложениями, которые подключаются к базе?
Мы создали библиотеку, которая эмулирует Oracle Instant Client.
Она позволяет переключать приложения с Oracle на Q.DataBase без перекомпиляции и изменений в коде.
Для приложений, использующих поддерживаемые функции «толстого» клиента, переход сводится к замене клиентской библиотеки и настройке подключения.
Приложение продолжает работать через привычный интерфейс.
Есть и другой вариант — подключение через наш JDBC-драйвер.
При этом на стороне Q.DataBase по-прежнему могут выполняться PL/SQL-конструкции.
Можно работать в любимом DBeaver, не замечая разницы и сохраняя привычный подход к работе с базой.
Драйверы скоро будут доступны для скачивания на нашем сайте, а пока выдаём их по запросу.
Достаточно оставить комментарий под постом, написать в личные сообщения или на почту supportqdb@diasoft.ru.
#Oracle #Импортозамещение #JDBC #qdb
Forwarded from Ассоциация Разработчиков СУБД RuDB
В этом посте я бы хотел кратко рассказать, чем же отличаются Digital Q.DataBase и RuDB и какие задачи решает каждый из этих продуктов.
Digital Q.DataBase — коммерческая СУБД для корпоративных заказчиков. Одна из ключевых задач, которую она решает: как перейти с Oracle и Microsoft SQL Server, сохранив прикладную логику и минимизировав переписывание кода?
У Ассоциации разработчиков СУБД, которая развивает RuDB, другой исходный вопрос: зачем каждому российскому разработчику СУБД на базе PostgreSQL самостоятельно реализовывать одни и те же технологии?
У таких разработчиков много общих задач: безопасность, перенос данных, повышение производительности, совместимость с российскими приложениями.
Если каждую из них все решают отдельно, значительная часть усилий уходит на повторение одной и той же работы.
Идея ассоциации — объединить усилия в этой общей части.
Совместно развивать технологическую основу, на которой участники смогут создавать собственные продукты и конкурентные преимущества.
Здесь важно различать саму ассоциацию и RuDB. Ассоциация объединяет разработчиков, а RuDB — технологический результат их совместной работы.
Подробнее о возможностях RuDB можно прочитать на сайте database.ru.
А сейчас давайте разберём один конкретный пример — совместимость с функциональностью пакетов Oracle.
Представим корпоративное приложение, которое много лет работало на Oracle.
Внутри него есть такой фрагмент PL/SQL-кода, как на слайде (2).
Здесь используется пакет DBMS_AQ — механизм Oracle Advanced Queuing.
Приложение формирует сообщение и вызовом DBMS_AQ.ENQUEUE помещает его в очередь.
Теперь мы хотим перенести это приложение на обычный PostgreSQL.
В стандартной поставке PostgreSQL такого пакета нет.
И задача не сводится к тому, чтобы заменить название процедуры или поправить синтаксис.
За этим вызовом стоит определённое поведение: постановка сообщения в очередь, его последующая обработка, связь с транзакцией.
Разработчику нужно подобрать замену и проверить, что она обеспечивает необходимое приложению поведение.
Это может потребовать изменений в коде, а иногда — и в архитектуре.
Например, если принято решение использовать внешнюю систему обмена сообщениями.
Именно здесь становится понятна ценность таких наработок в RuDB.
В RuDB реализована функциональность работы с очередями, соответствующая этому примеру.
Вместо пакетного вызова DBMS_AQ.ENQUEUE используется функция dbms_aq_enqueue.
Но это не означает, что исходный PL/SQL-код можно перенести без изменений.
Код потребуется адаптировать, а работу с параметрами, типами данных и транзакциями — проверить.
При этом разработчику уже не нужно с нуля создавать сам механизм очереди.
Он может использовать готовую реализацию и сосредоточиться на адаптации приложения.
RuDB сокращает объём работы по воспроизведению необходимой функциональности при миграции.
Digital Q.DataBase идёт дальше в части совместимости с исходным приложением: задача продукта — сохранить не только нужную функциональность, но и исходный код там, где поддерживается соответствующая совместимость.
В примере на слайде (2) это означает сохранение привычного пакетного вызова из PL/SQL.
Таким образом, различие можно сформулировать так:
В RuDB мы используем готовую функциональность и адаптируем под неё код.
В Digital Q.DataBase мы стремимся сохранить и функциональность, и исходный код приложения.
Поэтому RuDB нельзя рассматривать просто как бесплатную версию Digital Q.DataBase.
У них разные задачи:
RuDB даёт разработчикам общую технологическую основу, а Digital Q.DataBase помогает корпоративным заказчикам переносить существующие приложения с минимальными изменениями.
#RuDB #QDB #СУБД #НовостиСУБД #Oracle #PLSQL #Импортозамещение
Digital Q.DataBase — коммерческая СУБД для корпоративных заказчиков. Одна из ключевых задач, которую она решает: как перейти с Oracle и Microsoft SQL Server, сохранив прикладную логику и минимизировав переписывание кода?
У Ассоциации разработчиков СУБД, которая развивает RuDB, другой исходный вопрос: зачем каждому российскому разработчику СУБД на базе PostgreSQL самостоятельно реализовывать одни и те же технологии?
У таких разработчиков много общих задач: безопасность, перенос данных, повышение производительности, совместимость с российскими приложениями.
Если каждую из них все решают отдельно, значительная часть усилий уходит на повторение одной и той же работы.
Идея ассоциации — объединить усилия в этой общей части.
Совместно развивать технологическую основу, на которой участники смогут создавать собственные продукты и конкурентные преимущества.
Здесь важно различать саму ассоциацию и RuDB. Ассоциация объединяет разработчиков, а RuDB — технологический результат их совместной работы.
Подробнее о возможностях RuDB можно прочитать на сайте database.ru.
А сейчас давайте разберём один конкретный пример — совместимость с функциональностью пакетов Oracle.
Представим корпоративное приложение, которое много лет работало на Oracle.
Внутри него есть такой фрагмент PL/SQL-кода, как на слайде (2).
Здесь используется пакет DBMS_AQ — механизм Oracle Advanced Queuing.
Приложение формирует сообщение и вызовом DBMS_AQ.ENQUEUE помещает его в очередь.
Теперь мы хотим перенести это приложение на обычный PostgreSQL.
В стандартной поставке PostgreSQL такого пакета нет.
И задача не сводится к тому, чтобы заменить название процедуры или поправить синтаксис.
За этим вызовом стоит определённое поведение: постановка сообщения в очередь, его последующая обработка, связь с транзакцией.
Разработчику нужно подобрать замену и проверить, что она обеспечивает необходимое приложению поведение.
Это может потребовать изменений в коде, а иногда — и в архитектуре.
Например, если принято решение использовать внешнюю систему обмена сообщениями.
Именно здесь становится понятна ценность таких наработок в RuDB.
В RuDB реализована функциональность работы с очередями, соответствующая этому примеру.
Вместо пакетного вызова DBMS_AQ.ENQUEUE используется функция dbms_aq_enqueue.
Но это не означает, что исходный PL/SQL-код можно перенести без изменений.
Код потребуется адаптировать, а работу с параметрами, типами данных и транзакциями — проверить.
При этом разработчику уже не нужно с нуля создавать сам механизм очереди.
Он может использовать готовую реализацию и сосредоточиться на адаптации приложения.
RuDB сокращает объём работы по воспроизведению необходимой функциональности при миграции.
Digital Q.DataBase идёт дальше в части совместимости с исходным приложением: задача продукта — сохранить не только нужную функциональность, но и исходный код там, где поддерживается соответствующая совместимость.
В примере на слайде (2) это означает сохранение привычного пакетного вызова из PL/SQL.
Таким образом, различие можно сформулировать так:
В RuDB мы используем готовую функциональность и адаптируем под неё код.
В Digital Q.DataBase мы стремимся сохранить и функциональность, и исходный код приложения.
Поэтому RuDB нельзя рассматривать просто как бесплатную версию Digital Q.DataBase.
У них разные задачи:
RuDB даёт разработчикам общую технологическую основу, а Digital Q.DataBase помогает корпоративным заказчикам переносить существующие приложения с минимальными изменениями.
#RuDB #QDB #СУБД #НовостиСУБД #Oracle #PLSQL #Импортозамещение
🔥8