Друзья!

Совсем скоро — наша оффлайн-встреча в московском офисе 🍕

🗓 Когда: 20 августа (четверг), с 19:00 до 21:00
📍 Где: 127018, г. Москва, ул. Полковая, д. 3, строение 14

Пожалуйста, пройдите регистрацию, чтобы мы понимали, сколько готовить пиццы и мест 😉

https://forms.yandex.ru/u/6a7ee14795add5249c99894e

*Нам в регистрации по-сути нужны ФИО для пропуска.

По всем вопросам можете писать мне лично:
TG: zavrius
E-MAIL: azhuykov@diasoft.ru

Что Вас ждёт:
— Живое общение с командой разработки (под 🍕)
— Обсуждение планов развития Digital Q.DataBase
— Ваши вопросы и пожелания — без формальностей

До встречи!

#pizzaday

Индекс на булевом поле в PostgreSQL: мнимая оптимизация

Поставить индекс на колонку, где хранится только true или false (например, поле is_active для таблицы users), — это классика. Разработчик гордится проделанной "оптимизацией", но на деле это только пустая трата места на диске.

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

А что же делать? Выход есть — частичный индекс (CREATE INDEX ... WHERE ...). Он индексирует только те строки, которые вам реально нужны.

Например, если в таблице с пользователями большинство строк принадлежат уже активированным пользователям (is_active = true), а вы часто ищете только неактивированых (is_active = false), создайте индекс именно для них:

CREATE INDEX idx_inactive ON users (user_id) WHERE is_active IS FALSE;

Внимание: IS и = для булевых значений — не одно и то же! Для NULL они ведут себя по-разному. Если Вы создали частичный индекс с WHERE is_active IS FALSE, а в запросе напишете WHERE is_active = FALSE — частичный индекс не будет использован. Планировщик PostgreSQL весьма строг к буквальному совпадению условий 😈

P.S: Друзья, ждём Вас 20 августа покушать с нами пиццу в нашем офисе! 🍕
🔗 Регистрируйтесь по ссылке тут

OpenBPM и Digital Q.DataBase подтвердили совместимость

Хоулмонт и Диасофт подтвердили совместимость платформы OpenBPM и СУБД Digital Q.DataBase.
OpenBPM позволяет командам, работающим с Camunda, переносить существующие проекты на отечественный BPM-движок благодаря совместимости с API Camunda.

► Для заказчиков это ещё одна возможность использовать российскую СУБД в составе корпоративных BPM-решений.

Да, друзья, уже завтра — 20 августа! 🍕
Мы приглашаем абсолютно всех, кому интересен мир СУБД!

Пицца в обмен на вопросы о СУБД

Команда Digital Q.DataBase приглашает в свой московский офис на неформальную встречу.

► Мы угощаем пиццей и напитками, а вы приходите и задаёте любые вопросы о СУБД, команде разработки, возможностях продукта, миграции с Oracle и MS SQL Server и планах развития.

Digital Q.DataBase умеет исполнять диалекты Oracle и MS SQL прямо на лету, без предварительной конвертации кода.
Это позволяет переносить существующие приложения с минимальными изменениями.

🗓 20 августа, 19:00–21:00
📍 Москва, ул. Полковая, д. 3, стр. 14

► Регистрация:
https://forms.yandex.ru/u/6a7ee14795add5249c99894e

ФИО нужны для оформления пропуска.
Остальные поля — по желанию.

По всем вопросам: TG @zavrius или azhuykov@diasoft.ru

Ну и чтобы мы знали, сколько пиццы заказывать 😄

До встречи!

#БазыДанных #PostgreSQL #qdb

Диасофт и Медлайнсофт подтвердили совместимость СУБД Digital Q.DataBase и платформы "Медтера.Телемедицина".

Тестирование прошло на специализированном стенде. Проверили ключевые сценарии: ведение электронной медкарты по стандарту HL7 FHIR, телеконсультации, запись на прием, дневники здоровья и работу с множественным доступом к БД.

Друзья!

Вчера прошла наша встреча в московском офисе 🍕

Спасибо Всем, кто пришёл — было здорово!
Ваша обратная связь и внимание к продукту для нас бесценны.
Живое общение, вопросы, идеи — это то, что действительно помогает нам двигаться в правильном направлении.

Пицца была очень вкусной (честно!), обстановка — дружеской и неформальной. Мы получили от встречи огромный заряд энергии и вдохновения для новых шагов по развитию нашей СУБД.

И хорошая новость для тех, кто не смог приехать: обязательно повторим!
Следующий на очереди — Питер. О датах сообщим отдельно.

Спасибо, что Вы с нами 🙌

Необычные проекты на SQL

Мы уже рассказывали Вам о нетипичном применении SQL в одном из более ранних постов.

Пришло время пополнить коллекцию новыми экземплярами. В этот раз для СУБД ClickHouse:

1. Трассировка лучей (RayTracer)
Полноценный path tracer, написанный целиком на ClickHouse SQL. Рендеринг выполняется одним SELECT-запросом без UDF и внешнего кода, сохраняя результат сразу в PNG. Каждый пиксель — отдельная строка, 3D-математика построена на кортежах (Tuple(Float64, Float64, Float64)), а цикл отражений реализован через arrayFold. Сцена включает стеклянные и хромированные буквы "ClickHouse" над процедурно-генерируемым ландшафтом с отражениями и тенями.

2. Doom-подобная игра (DOOMHouse)
Игровой движок, рендерящий 3D-графику целиком в ClickHouse SQL.

3. Эмулятор RISC-V (Click-V)
Эмулятор процессора RISC-V, написанный на ClickHouse SQL. Использует материализованные представления для симуляции регистров и памяти. Автор шутит, что это делает ClickHouse "истинно полным по Тьюрингу".

4. Синтезатор музыки (NoiSQL)
Генерация музыки декларативными SQL-запросами. Содержит осцилляторы, огибающие, секвенсоры, арпеджиаторы, эффекты (дисторшн, задержка), генераторы шума, AM/FM и LFO.

Эти проекты — не просто забава. Они демонстрируют, что современные СУБД, являются мощными векторными движками, которые можно использовать для решения самых неожиданных вычислительных задач.

Это подтверждает, что границы SQL простираются далеко за рамки традиционных представлений.

Ссылки на проекты:
· RayTracer: github.com/ClickHouse/RayTracer
· DOOMHouse: github.com/arniwesth/DoomHouse
· Click-V: github.com/SpencerTorres/Click-V
· NoiSQL: github.com/ClickHouse/NoiSQL

Название, которое не любят

В 1996 году проект Postgres95 был переименован в PostgreSQL, чтобы подчеркнуть поддержку SQL.

В 2018 году один из основателей, Том Лейн, назвал это решение «вероятно, самой худшей ошибкой за всю историю проекта».

С тех пор сообщество дружно использует короткое «Postgres» — и даже разработчики в документации часто пишут именно так.

А ещё у PostgreSQL-сообщества есть собственный "шибболет" (слово, по произношению которого отличают своих от чужих): правильно говорить «пост-грес» или «пост-грес-кью-эл». Варианты «пост-гре» или «пост-грес-эс-кью-эль» мгновенно выдают "чужого". Проверьте коллег! 😉

Дорогие подписчики!

Сегодня я хочу напомнить Вам о нашем аналоге SQL Server Reporting Services - Служба отчётов DIGITAL Q.DATABASE

Что доступно в текущей версии:

· Обработка данных и выполнение запросов;
· Выражения, группировки и итоги;
· Табличный компонент (Tablix) для гибкого вывода данных;
· Master-detail (связь основного и подчинённых отчётов);
· Отчёты с изображениями;
· Форматирование чисел и дат;
· Разбивка на страницы, колонтитулы, стили;
· Экспорт готовых отчётов в HTML и PDF.

🔗 Скачать дистрибутив можно на официальном сайте https://database.diasoft.ru
Обратите внимание: это отдельный дистрибутив, устанавливаемый независимо от СУБД.
Доступен под все поддерживаемые операционные системы.

Вопросы по настройке и внедрению можно направлять на наш адрес службы поддержки: supportqdb@diasoft.ru

Уважаемые подписчики!

Сегодня хочу напомнить Вам про Мастер сравнения БД — это инструмент, входящий в состав дистрибутива Digital Q.DataBase, предназначенный для проверки корректности миграции данных.

Он сравнивает схемы баз данных и количество объектов между исходной и целевой БД.

Поддерживаются:
Microsoft SQL Server
Oracle Database
PostgreSQL

Что умеет:
находит различия в таблицах, представлениях, индексах, триггерах, функциях и ограничениях,
проверяет расхождения в количестве строк
формирует понятный отчёт.

Работает в двух форматах:

Десктоп
(через пошаговый мастер)

Консоль
(через YAML-конфигурации)

Доступен на Linux и Windows - удобно и для админов, и для автоматизации.

Мастер сравнения БД - это удобный финальный чек после миграции: данные доехали, а структура совпала.

В этом посте кратко хочу отметить, как последняя версия Digital Q.DataBase 18.2 воспроизводит сразу три SQL-диалекта: PL/pgSQL, PL/SQL и T-SQL.

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

В версии 18.2 архитектура принципиально меняется.
Теперь перед нами уже не один большой серверный процесс с тремя обработчиками, а три самостоятельных модуля: Pearl, Onyx и Marble.

Pearl — модуль PostgreSQL;

Onyx — модуль, воспроизводящий функциональность Oracle Database;

Marble — модуль, воспроизводящий функциональность Microsoft SQL Server;

Каждый модуль получил собственный серверный процесс бэкенда и собственный полный конвейер обработки запроса.

То есть запрос PostgreSQL приходит в Pearl и внутри Pearl проходит свой путь: парсер, мутатор, планирование, оптимизация и исполнение.
Oracle-совместимый запрос приходит уже в Onyx. У него свой менеджер соединений, свой серверный процесс, свой обработчик PL/SQL и свой конвейер выполнения.
То же самое происходит с T-SQL в Marble: TDS-клиент подключается к Marble, и дальше запрос обрабатывается уже внутри собственного серверного процесса этого модуля.

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

При этом они НЕ превращаются в три совершенно независимые СУБД.

В нижней части схемы как раз показано то, что их объединяет. 
Здесь находятся поддержка кросс-модульных взаимодействий с общими процессами хранения, монитор состояния системных служб, in-memory сервер DGrid, постоянное Key-Value хранилище RocksDB и механизм поколонного хранения MergeTree.

Каждый модуль можно развернуть на одной ноде либо распределить модули по трём отдельным нодам - в зависимости от требований к инфраструктуре.

В продолжение предыдущего поста — немного о Digital Q.DataBase с точки зрения системного администрирования.

Установочный пакет бесплатно скачивается с нашего сайта database.diasoft.ru в формате tar.gz

На примере Astra Linux 1.8 видно, что внутри находятся необходимые серверные deb-пакеты: pearl, marble и onyx.

Установка выполняется стандартным способом через sudo apt install.
Причём модули можно устанавливать как на одну ноду, так и распределять, например, на три — в зависимости от архитектуры вашей системы.

В архиве также есть всё необходимое для работы:

— серверная и клиентская части в qdb-server-client;
— etcd для конфигурации;
— patroni для обеспечения отказоустойчивости;
— pgbouncer для пула соединений;
— vip-manager для плавающего IP-адреса;
— пакет безопасности securityextensions;
— утилиты для переноса данных;
— документация и инструкции.

Отдельно стоит отметить папку samples — в ней находятся готовые T-SQL и PL/SQL-скрипты, которые можно использовать для быстрой проверки функциональности после установки.

Для каждого механизма есть собственный мануал в формате TXT или PDF.
В комплекте также находятся документация по Мастеру переноса, Мастеру сравнения, Руководство пользователя, README с заметками по установке и release_notes с краткой сводкой изменений версии 18.2.

Человек без ученой степени, который построил первую СУБД и получил за это Премию Тьюринга

В начале 1960‑х инженер Чарльз Бахман работал в General Electric и столкнулся с проблемой: данные хранились хаотично, каждый раз приходилось писать новый код для доступа к ним. Его решение — Integrated Data Store (IDS) — стало первой в мире успешной системой управления базами данных, которая позволяла связывать записи и управлять ими без переписывания программ.

Прошло чуть больше десятилетия, и в 1973 году Бахману вручили Премию Тьюринга — высшую награду в компьютерных науках. Событие было настоящей сенсацией, так как он стал первым лауреатом этой премии без PhD и без академического бэкграунда. Инженер-механик по образованию, чистый практик, который просто решал реальные задачи для компании, в которой он работал.

Но на этом история не заканчивается. В 1974 году на легендарной "Великой дискуссии" он на равных спорил с самим Эдгаром Коддом — отцом реляционной модели данных. Бахман отстаивал сетевой подход, Кодд — реляционный. Их спор не был враждой: они признавали заслуги друг друга, а сам Кодд называл IDS «первой настоящей системой баз данных». Эта полемика двигала вперёд всю индустрию.

Итог: человек без учёной степени изменил мир данных, а потом встал в один ряд с величайшими теоретиками. Иногда достаточно просто делать своё дело хорошо!

Когда твоя база данных становится умнее тебя или как ИИ проникает внутрь современных СУБД

Раньше ИИ и база данных жили раздельно: данные хранились в СУБД, а модели крутились где-то рядом. Теперь стена рушится — искусственный интеллект переезжает прямо внутрь СУБД. Вот что происходит прямо сейчас.

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 полностью? Или это всё равно потребует человеческого контроля? Будем рады обменяться мнениями в комментариях 👇