Померимся цифрами?
❓ Есть ли связь между количеством строк исходного кода и богатством функциональных и нефункциональных возможностей СУБД? Скорее да, чем нет. Хотя конечно речь не о жестком соотношении, а скорее о корреляции этих показателей.
✅ В PostgreSQL на сегодня — около 2,1 млн строк на языке C. Много ли это? Зависит от того, с чем сравнивать.
✅ Например, в MySQL на сегодня 2.4 миллиона строк кода (С/С++), в MongoDB - чуть больше 2 миллионов строк С++ кода, в российском ClickHouse - 1.5 миллиона строк кода на языке С++, а в вот в SQLite всего 145 тысяч строк кода (на чистом С).
✅ Особняком в этом ряду стоит СУБД Oracle. В 1992 году в 7-ой версии этой СУБД было 1.5 миллиона строк кода на языке С, к 12-й версии (2017) размер кодовой базы дорос аж до 25 млн, а сейчас, по разным оценкам, он насчитывает от 35 до 40 млн строк исходного кода.
Для понимания: одна только подсистема RAC в Oracle "весит" 1,6 млн строк, а in-memory-подсистема - почти 2 млн. Это сопоставимо с размером последней версии "ванильного" PostgreSQL.
✅ В нашей СУБД Digital Q.DataBase по состоянию на сегодня 4.6 миллиона строк исходного кода, из них 2.7 миллиона строк это код на чистом С, еще 0.3 миллиона строк это код на разных диалектах SQL, а остальное - это код на С++.
Да, это более чем двукратный рост по сравнению с размером кода оригинального PostgreSQL, но всё же нам есть еще куда расти.
✅ Правда, у роста кодовой базы есть и обратная сторона. Говорят, что программный код Oracle 12 был настолько запутанным, что любое его изменение с высокой вероятностью ломало регрессионные тесты. Разработчикам приходилось действовать крайне осторожно внося изменения — своего рода плата за десятилетия эволюции.
✅ Так что пожелаем российским форкам PostgreSQL прирастать функциональностью и связанным с ней кодом (до 10–20 млн строк, почему бы и нет!), но при этом сохранять архитектурную внятность кода и надёжность тестов. Чтобы становиться сильнее, радовать новыми возможностями пользователей, но при этом не повторять чужих ошибок.
Для понимания: одна только подсистема RAC в Oracle "весит" 1,6 млн строк, а in-memory-подсистема - почти 2 млн. Это сопоставимо с размером последней версии "ванильного" PostgreSQL.
Да, это более чем двукратный рост по сравнению с размером кода оригинального PostgreSQL, но всё же нам есть еще куда расти.
Please open Telegram to view this post
VIEW IN TELEGRAM
Мы поддержали новый пакет HTP.
Для чего он нужен
Основные функции
· PRINT — вывод произвольной HTML-строки;
· HTMLOPEN / HTMLCLOSE — открытие и закрытие тега <HTML>;
· HEADOPEN / HEADCLOSE — открытие и закрытие тега <HEAD>;
· BODYOPEN / BODYCLOSE — открытие и закрытие тега <BODY>;
· TITLE — генерация тега <TITLE>;
· HEADER — генерация заголовков <H1>...<H6>;
Пример использования
CREATE OR REPLACE PROCEDURE hello AS
BEGIN
HTP.HTMLOPEN;
HTP.HEADOPEN;
HTP.TITLE('Привет');
HTP.HEADCLOSE;
HTP.BODYOPEN;
HTP.HEADER(1, 'Digital Q.DataBase');
HTP.PRINT('Добро пожаловать');
HTP.BODYCLOSE;
HTP.HTMLCLOSE;
END;
Please open Telegram to view this post
VIEW IN TELEGRAM
Дорогие подписчики!
➡️ Продолжаем рассказывать о встроенных пакетах Digital Q.DataBase, обеспечивающих совместимость с PL/SQL-окружением Oracle.
Мы поддержали новый пакет OWA_MATCH.
Для чего он нужен
➡️ Пакет OWA_MATCH предоставляет функцию MATCH_PATTERN для проверки строк на соответствие заданным шаблонам с учётом специальных символов . Он позволяет определить, содержит ли строка недопустимые символы или соответствует ли одному из исключающих правил .
Основные возможности
· Проверка строки на наличие специальных символов из заданного списка;
· Сравнение со списком простых шаблонов (с использованием оператора LIKE);
· Сравнение со списком сложных шаблонов (с использованием регулярных выражений через OWA_PATTERN);
· Возможность отключить проверку специальных символов через параметр p_use_special_chars.
Пример использования
Мы поддержали новый пакет OWA_MATCH.
Для чего он нужен
Основные возможности
· Проверка строки на наличие специальных символов из заданного списка;
· Сравнение со списком простых шаблонов (с использованием оператора LIKE);
· Сравнение со списком сложных шаблонов (с использованием регулярных выражений через OWA_PATTERN);
· Возможность отключить проверку специальных символов через параметр p_use_special_chars.
Пример использования
-- Проверка строки на соответствие шаблонам
DECLARE
v_simple owa_util.vc_arr;
v_complex owa_util.vc_arr;
v_result BOOLEAN;
BEGIN
v_simple(1) := '%test%';
v_complex(1) := '^[A-Z]+$';
v_result := owa_match.match_pattern(
p_string => 'TEST',
p_simple_pattern => v_simple,
p_complex_pattern => v_complex,
p_use_special_chars => TRUE
);
IF v_result THEN
DBMS_OUTPUT.PUT_LINE('Строка соответствует шаблону');
END IF;
END;
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня — OWA_PATTERN.
Для чего он нужен
Основные функции
· AMATCH — поиск подстроки, соответствующей регулярному выражению;
· MATCH — проверка, соответствует ли строка целиком заданному шаблону;
· CHANGE — замена подстроки, найденной по регулярному выражению;
· CHANGE_ALL — замена всех вхождений, соответствующих шаблону.
Пример использования
-- Проверка, соответствует ли строка регулярному выражению
DECLARE
v_result BOOLEAN;
BEGIN
v_result := OWA_PATTERN.MATCH('abc123', '[a-z]+[0-9]+');
IF v_result THEN
DBMS_OUTPUT.PUT_LINE('Строка соответствует шаблону');
END IF;
END;
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Напоминаем: уже завтра День партнёров Диасофт!
💌 Приглашаем на третью партнёрскую конференцию, которая состоится завтра, 29 мая.
⚡️ Фокус деловой программы — искусственный интеллект в развитии ERP-решений и новые ИТ-стандарты. Эксперты продемонстрируют возможности экосистемы Digital Q, в которую ИИ уже интегрирован.
Для тех, кто следит за развитием Digital Q.DataBase
🐬 На конференции будет работать наш стенд, где можно вживую пообщаться с представителями команды разработки СУБД. Расскажем о планах развития, ответим на вопросы, обсудим сценарии использования и миграции.
🎉 К вечеру деловую программу сменит развлекательная — с лучшим трибьют-шоу АВВА в России!
Регистрация по ссылке:
https://dpd3.diasoft.ru/
До встречи офлайн!
💌 Приглашаем на третью партнёрскую конференцию, которая состоится завтра, 29 мая.
Для тех, кто следит за развитием Digital Q.DataBase
Регистрация по ссылке:
https://dpd3.diasoft.ru/
До встречи офлайн!
Please open Telegram to view this post
VIEW IN TELEGRAM
Мы поддержали новый пакет OWA_TEXT.
Для чего он нужен
Основные возможности
· UPPER — преобразование строки в верхний регистр;
· LOWER — преобразование строки в нижний регистр;
· INITCAP — преобразование первого символа каждого слова в заглавный;
· TRIM — удаление пробелов в начале и конце строки;
· SUBSTR — извлечение подстроки из строки;
· LENGTH — определение длины строки;
· LPAD / RPAD — дополнение строки символами слева или справа до заданной длины;
· REPLACE — замена одной подстроки на другую.
Пример использования
-- Преобразование строки в верхний регистр
DECLARE
v_text VARCHAR2(100) := 'digital q.database';
BEGIN
v_text := OWA_TEXT.UPPER(v_text);
DBMS_OUTPUT.PUT_LINE(v_text); -- Результат: DIGITAL Q.DATABASE
END;
-- Удаление лишних пробелов и преобразование регистра
DECLARE
v_text VARCHAR2(100) := ' hello world ';
BEGIN
v_text := OWA_TEXT.TRIM(v_text);
v_text := OWA_TEXT.UPPER(v_text);
DBMS_OUTPUT.PUT_LINE(v_text); -- Результат: HELLO WORLD
END;
Please open Telegram to view this post
VIEW IN TELEGRAM
В феврале 2025 года Alibaba Cloud PolarDB обновила мировой рекорд TPC-C: 2,055 млрд транзакций в минуту (tpmC). Это в 2,5 раза выше их же предыдущего достижения.
Разработчики позже признали: они могли бы показать и большие показатели по числу транзакций в минуту, если бы не просчет с емкостью дисков. По условиям теста TPC-C в котором эмулируется работа складов, каждый склад добавляет фиксированное количество данных. Именно емкость дисков просто не позволила добавить еще несколько складов, хотя по нагрузке процессоров еще оставался вполне приличный запас. Теоретически на том же «железе» можно выжать до 2,8 млрд tpmC, то есть на 36% больше текущего мирового рекорда.
https://tpc.org//tpcc/results/tpcc_results5.asp
Please open Telegram to view this post
VIEW IN TELEGRAM
tpc.org
TPC-C All Results
The Transaction Processing Performance Council (TPC) defines Transaction Processing and Database Benchmarks and delivers trusted results to the industry.
У финского программиста Монти Видениуса (создателя MySQL и MariaDB, одного из авторов MaxDB) трое детей: дочери Май и Мария и сын Макс.
Их имена он увековечил в названиях своих СУБД:
• MySQL — в честь старшей дочери Май
• MariaDB — в честь средней дочери Марии
• MaxDB — в честь сына Макса
Так что это не «моя SQL» и не «максимальная база данных», а просто любящий папа, который назвал три своих продукта в честь троих своих детей. Продал одну компанию Oracle — создал форк в честь другой дочери. Сын тоже не остался без внимания.
Вот такое семейное open-source счастье
Please open Telegram to view this post
VIEW IN TELEGRAM
Дорогие подписчики!
✅ Добавляем ещё один кирпичик в PL/SQL-совместимость Digital Q.DataBase.
Сегодня — пакет OWA_UTIL.
Для чего он нужен
✅ Пакет OWA_UTIL предоставляет набор вспомогательных утилит для работы с веб-приложениями. Он включает функции для обработки массивов, форматирования вывода, работы с динамическим SQL и управления параметрами запросов.
Основные функции
· BIND_VARIABLES — привязка переменных в динамическом SQL;
· CELLSPRINT — форматирование вывода в HTML-таблицу;
· GET_CGI_ENV — получение значений CGI-переменных окружения;
· LISTPRINT — вывод содержимого массива;
· SHOWPAGE — вывод HTML-страницы с заголовками;
· VC_ARR — тип данных для работы с массивами переменной длины;
· TABLEPRINT — вывод данных в виде HTML-таблицы.
Пример использования
Сегодня — пакет OWA_UTIL.
Для чего он нужен
Основные функции
· BIND_VARIABLES — привязка переменных в динамическом SQL;
· CELLSPRINT — форматирование вывода в HTML-таблицу;
· GET_CGI_ENV — получение значений CGI-переменных окружения;
· LISTPRINT — вывод содержимого массива;
· SHOWPAGE — вывод HTML-страницы с заголовками;
· VC_ARR — тип данных для работы с массивами переменной длины;
· TABLEPRINT — вывод данных в виде HTML-таблицы.
Пример использования
-- Вывод содержимого массива
DECLARE
v_arr owa_util.vc_arr;
BEGIN
v_arr(1) := 'строка 1';
v_arr(2) := 'строка 2';
v_arr(3) := 'строка 3';
owa_util.listprint(v_arr);
END;
Please open Telegram to view this post
VIEW IN TELEGRAM
Когда база данных начинает «тормозить», DBA часто превращается в детектива:
SQL-консоль, логи, мониторинг, Excel-таблицы, серверные скрипты - и всё это одновременно.
Центр управления Digital Q.DataBase решает эту проблему через единое окно управления БД:
— мониторинг и диагностика в одном интерфейсе
— поиск проблем за минуты, а не часы
— анализ блокировок, ожиданий и медленных SQL
— контроль роста данных и производительности
— централизованное управление инфраструктурой
— поддержка Digital Q.DataBase и PostgreSQL
Что особенно важно:
Please open Telegram to view this post
VIEW IN TELEGRAM
«Мониторинг должен отвечать не только на вопрос “что сломалось”, но и “почему это произошло”».
Одна из ключевых проблем эксплуатации СУБД — разрозненность инструментов:
SQL-консоли, логи, трассировки, метрики, shell-скрипты и отдельные системы мониторинга существуют сами по себе и усложняют диагностику.
Именно поэтому особенно важен подход единого центра управления, где в одном интерфейсе доступны:
— состояние экземпляров БД
— активные сессии и ожидания
— блокировки и SQL statistics
— анализ прироста данных
— диагностика производительности
— централизованный мониторинг инфраструктуры
чем быстрее инженер может локализовать узкое место, тем ниже риск деградации сервисов, простоя и каскадных проблем в бизнес-приложениях.
Хороший мониторинг — это уже не “посмотреть графики”, а полноценный инструмент оперативной диагностики и управления производительностью СУБД.
Please open Telegram to view this post
VIEW IN TELEGRAM
Дорогие подписчики!
➡️ Продолжаем пополнять набор встроенных пакетов Digital Q.DataBase.
Добавлен DBMS_FILE_TRANSFER.
Для чего он нужен
➡️ Пакет предназначен для копирования файлов между каталогами на сервере, а также между локальным и удалённым серверами. Работает с бинарными и текстовыми файлами через объекты DIRECTORY.
Основные функции
· COPY_FILE — копирование файла внутри сервера;
· GET_FILE — получение файла с удалённого сервера;
· PUT_FILE — отправка файла на удалённый сервер;
· RENAME_FILE — переименование файла;
· DELETE_FILE — удаление файла.
Пример использования
Добавлен DBMS_FILE_TRANSFER.
Для чего он нужен
Основные функции
· COPY_FILE — копирование файла внутри сервера;
· GET_FILE — получение файла с удалённого сервера;
· PUT_FILE — отправка файла на удалённый сервер;
· RENAME_FILE — переименование файла;
· DELETE_FILE — удаление файла.
Пример использования
BEGIN
DBMS_FILE_TRANSFER.COPY_FILE(
source_directory_object => 'SRC_DIR',
source_file_name => 'backup.dmp',
destination_directory_object => 'DEST_DIR',
destination_file_name => 'backup_copy.dmp'
);
END;
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Diasoft о технологиях по-настоящему
Digital Q.DataBase – в ТОП-3 лучших СУБД в обзоре "Российские СУБД на базе PostgreSQL" 🏆
Диасофт и другие российские разработчики предложили рынку собственные дистрибутивы PostgreSQL, оптимизированные под запросы крупного бизнеса.
В исследовании эксперты "Ланит" сравнили пять продуктов лидеров рынка по восьми группам параметров:
🔵 общие характеристики;
🔵 безопасность;
🔵 масштабируемость и надежность;
🔵 производительность;
🔵 удобство сопровождения;
🔵 удобство разработки;
🔵 миграция;
🔵 возможности графического интерфейса.
СУБД Digital Q.DataBase показала отличные результаты, заняв1️⃣ место по критерию "Удобство разработки", 2️⃣ место за миграционные возможности и 3️⃣ место по общим характеристикам.
Диасофт и другие российские разработчики предложили рынку собственные дистрибутивы PostgreSQL, оптимизированные под запросы крупного бизнеса.
В исследовании эксперты "Ланит" сравнили пять продуктов лидеров рынка по восьми группам параметров:
СУБД Digital Q.DataBase показала отличные результаты, заняв
Please open Telegram to view this post
VIEW IN TELEGRAM
Первая архитектура данных: как шумеры строили OLTP, DWH и реестры сотрудников за 4000 лет до нашей эры
В период Третьей династии Ура (XXI в. до н. э.) шумеры создали государственную учётную систему на глиняных табличках. По своей сути — полноценную иерархическую СУБД с первичными документами, агрегатами, реестрами мастер-данных и аутентификацией.
📁 Иерархия табличек
Система строилась на трёх уровнях:
1. Детальные транзакции — таблички, фиксирующие проведенные операции: «в дату какую-то выдано 5 мер зерна гонцу Или-шинату».
2. Периодические сводки — агрегация количественных данных за неделю или месяц с группировкой по типу операции.
3. Мастер-табличка — итоговый документ периода, суммирующий все поступления и расходы. Документ содержал начальный остаток, приход и расход за период и итоговый остаток.
Таблички одного периода собирались в корзину и снабжались глиняным ярлыком-описью — это своего рода физический аналог S3 Glacier с каталогом содержимого.
👥 Реестры чиновников, воинов и рабочих
Государство вело детальные реестры по категориям населения. Например, сохранилась административная бирка из Гирсу, где перечислены типы учётных документов в архиве. Среди учтённых категорий населения были чиновники и управленцы (землемеры, надзиратели зернохранилищ, писцы), воины, работники (пахари, строители, носильщики и т.п.).
Атрибуты строки в реестре работников включали: профессию, специализацию, участок работ, статус (активен/умер в пути), имя бригадира.
Одна из сохранившихся табличек 2027 г. до н. э. содержит поимённый перечень персонала храмового хозяйства с указанием их пайков.
Для учёта трудозатрат применялась агрегация в стиле: «14 работников × 15 дней = 210 человеко-дней» — детали и свод одновременно. Правда система счисления использовалась шестидесятиричная (кстати, именно из Шумера идет наше исчисление времени: деление часа на 60 минут, а минуты на 60 секунд).
🖊️ Подпись данных и защита от их изменения
С 3500 г. до н.э. в Шумере активно использовались цилиндрические печати — персональные идентификаторы чиновников. Они представляли собой резной цилиндр, который прокатывался по еще влажной глине только что составленного документа, после чего на нем оставался уникальный рельефный рисунок и имя владельца печати. После нанесения рельефа было невозможно что-то дописать или стереть.
Пример из документа об оплате труда (ок. 2033 г. до н. э.): в конце таблички указано «[запечатано] Ур-Шульпаэ, сыном Лугаль-кугани». Это буквально аутентификация транзакции.
Иногда использовалось коллегиальное подтверждение – документ "подписывали" сразу несколько человек.
♻️ Жизненный цикл данных
Хранение: таблички в корзинах — архивный слой с медленным доступом.
Уничтожение: документы с истекшей юридической силой физически разбивали. Аналог современного hard delete без возможности восстановления.
Вывод: Шумерская информационная система включала в себя разделение на транзакционный и аналитический слои, мастер-данные по персоналу, агрегацию в итоговых табличках и механизм подтверждения подлинности. Это первая известная нам реализация принципов, которые сегодня лежат в основе многих современных бизнес-систем.
В период Третьей династии Ура (XXI в. до н. э.) шумеры создали государственную учётную систему на глиняных табличках. По своей сути — полноценную иерархическую СУБД с первичными документами, агрегатами, реестрами мастер-данных и аутентификацией.
📁 Иерархия табличек
Система строилась на трёх уровнях:
1. Детальные транзакции — таблички, фиксирующие проведенные операции: «в дату какую-то выдано 5 мер зерна гонцу Или-шинату».
2. Периодические сводки — агрегация количественных данных за неделю или месяц с группировкой по типу операции.
3. Мастер-табличка — итоговый документ периода, суммирующий все поступления и расходы. Документ содержал начальный остаток, приход и расход за период и итоговый остаток.
Таблички одного периода собирались в корзину и снабжались глиняным ярлыком-описью — это своего рода физический аналог S3 Glacier с каталогом содержимого.
👥 Реестры чиновников, воинов и рабочих
Государство вело детальные реестры по категориям населения. Например, сохранилась административная бирка из Гирсу, где перечислены типы учётных документов в архиве. Среди учтённых категорий населения были чиновники и управленцы (землемеры, надзиратели зернохранилищ, писцы), воины, работники (пахари, строители, носильщики и т.п.).
Атрибуты строки в реестре работников включали: профессию, специализацию, участок работ, статус (активен/умер в пути), имя бригадира.
Одна из сохранившихся табличек 2027 г. до н. э. содержит поимённый перечень персонала храмового хозяйства с указанием их пайков.
Для учёта трудозатрат применялась агрегация в стиле: «14 работников × 15 дней = 210 человеко-дней» — детали и свод одновременно. Правда система счисления использовалась шестидесятиричная (кстати, именно из Шумера идет наше исчисление времени: деление часа на 60 минут, а минуты на 60 секунд).
🖊️ Подпись данных и защита от их изменения
С 3500 г. до н.э. в Шумере активно использовались цилиндрические печати — персональные идентификаторы чиновников. Они представляли собой резной цилиндр, который прокатывался по еще влажной глине только что составленного документа, после чего на нем оставался уникальный рельефный рисунок и имя владельца печати. После нанесения рельефа было невозможно что-то дописать или стереть.
Пример из документа об оплате труда (ок. 2033 г. до н. э.): в конце таблички указано «[запечатано] Ур-Шульпаэ, сыном Лугаль-кугани». Это буквально аутентификация транзакции.
Иногда использовалось коллегиальное подтверждение – документ "подписывали" сразу несколько человек.
♻️ Жизненный цикл данных
Хранение: таблички в корзинах — архивный слой с медленным доступом.
Уничтожение: документы с истекшей юридической силой физически разбивали. Аналог современного hard delete без возможности восстановления.
Вывод: Шумерская информационная система включала в себя разделение на транзакционный и аналитический слои, мастер-данные по персоналу, агрегацию в итоговых табличках и механизм подтверждения подлинности. Это первая известная нам реализация принципов, которые сегодня лежат в основе многих современных бизнес-систем.
Построено навечно
Кажется, что некоторые технологии прошлого буквально обречены на вечную жизнь.
Например, немецкая СУБД Adabas, которая была выпущена в 1971 году, пережила расцвет мейнфреймов, эпоху реляционных баз данных и не только не канула в Лету, но живет полной жизнью и имеет большое сообщество пользователей.
Вот несколько фактов об этой живучей системе:
📜 Глубокая история: Эта СУБД была выпущена для мейнфреймов IBM еще в 1971 году и уже в 1983 году занимала 11% мирового рынка.
⚙️ Уникальная архитектура: Отличается моделью данных на базе инвертированного индекса, впоследствии дополненной реляционными элементами.
⚡ Скорость и надежность: Может обслуживать десятки тысяч параллельно работающих пользователей и обрабатывать более 2 миллионов запросов в секунду, обеспечивая самую низкую стоимость транзакции из официально зарегистрированных.
🚀 Развитие и планы на будущее: Adabas был портирован на Linux, Unix и Windows, поддерживает Unicode, имеет облачную версию, активно продвигается, проводит вебинары и живет по долгосрочной стратегии развития, охватывающей интервал до 2050 года.
👶 Известные наследники: СУБД SAP MaxDB и СУБД SAP HANA являются прямыми потомками ("внук" и "правнук") СУБД Adabas и используют внутри её наработки.
Многие крупные зарубежные авиакомпании до сих пор используют в системах продажи авиабилетов СУБД Adabas.
👴 Другие СУБД-долгожители
Adabas не одинок в клубе старейшин мира СУБД.
Вот ещё ряд примеров СУБД, чей возраст перевалил за несколько десятилетий, но они все еще в строю:
· IMS (Information Management System) от IBM: Была создана в 1968 году для программы «Аполлон». До сих пор является основой многих критически важных систем в зарубежных банках и страховых компаниях.
· Oracle Database: Первая в мире коммерчески успешная реляционная СУБД. Была выпущена в 1979 году, но до сих пор занимает огромную долю рынка.
· Советская СУБД «Ника»: Прямой наследник выпущенной в конце 70-х СУБД ИНЕС, которая во второй половине 80-х работала практически на каждом третьем компьютере ЕС ЭВМ в стране. «Ника» включена в Единый реестр российского ПО и до сих пор эксплуатируется и сопровождается.
Кажется, что некоторые технологии прошлого буквально обречены на вечную жизнь.
Например, немецкая СУБД Adabas, которая была выпущена в 1971 году, пережила расцвет мейнфреймов, эпоху реляционных баз данных и не только не канула в Лету, но живет полной жизнью и имеет большое сообщество пользователей.
Вот несколько фактов об этой живучей системе:
📜 Глубокая история: Эта СУБД была выпущена для мейнфреймов IBM еще в 1971 году и уже в 1983 году занимала 11% мирового рынка.
⚙️ Уникальная архитектура: Отличается моделью данных на базе инвертированного индекса, впоследствии дополненной реляционными элементами.
⚡ Скорость и надежность: Может обслуживать десятки тысяч параллельно работающих пользователей и обрабатывать более 2 миллионов запросов в секунду, обеспечивая самую низкую стоимость транзакции из официально зарегистрированных.
🚀 Развитие и планы на будущее: Adabas был портирован на Linux, Unix и Windows, поддерживает Unicode, имеет облачную версию, активно продвигается, проводит вебинары и живет по долгосрочной стратегии развития, охватывающей интервал до 2050 года.
👶 Известные наследники: СУБД SAP MaxDB и СУБД SAP HANA являются прямыми потомками ("внук" и "правнук") СУБД Adabas и используют внутри её наработки.
Многие крупные зарубежные авиакомпании до сих пор используют в системах продажи авиабилетов СУБД Adabas.
👴 Другие СУБД-долгожители
Adabas не одинок в клубе старейшин мира СУБД.
Вот ещё ряд примеров СУБД, чей возраст перевалил за несколько десятилетий, но они все еще в строю:
· IMS (Information Management System) от IBM: Была создана в 1968 году для программы «Аполлон». До сих пор является основой многих критически важных систем в зарубежных банках и страховых компаниях.
· Oracle Database: Первая в мире коммерчески успешная реляционная СУБД. Была выпущена в 1979 году, но до сих пор занимает огромную долю рынка.
· Советская СУБД «Ника»: Прямой наследник выпущенной в конце 70-х СУБД ИНЕС, которая во второй половине 80-х работала практически на каждом третьем компьютере ЕС ЭВМ в стране. «Ника» включена в Единый реестр российского ПО и до сих пор эксплуатируется и сопровождается.
Дорогие подписчики!
➡️ Ещё один пакет для PL/SQL-совместимости Digital Q.DataBase — DBMS_NETWORK_ACL_ADMIN.
Для чего он нужен
➡️ Пакет предоставляет интерфейс для управления сетевыми списками контроля доступа (ACL) . ACL используются для ограничения доступа пользователей к внешним сетевым ресурсам через PL/SQL-пакеты: UTL_TCP, UTL_HTTP, UTL_SMTP, UTL_INADDR .
Основные функции
· APPEND_HOST_ACE — добавление записи ACL для хоста с указанием прав (connect, resolve);
· REMOVE_HOST_ACE — удаление записи ACL для хоста;
· SET_HOST_ACL — назначение ACL для хоста или домена;
· APPEND_WALLET_ACE — добавление записи ACL для wallet (хранилища сертификатов);
· REMOVE_WALLET_ACE — удаление записи ACL для wallet.
Пример использования
Для чего он нужен
Основные функции
· APPEND_HOST_ACE — добавление записи ACL для хоста с указанием прав (connect, resolve);
· REMOVE_HOST_ACE — удаление записи ACL для хоста;
· SET_HOST_ACL — назначение ACL для хоста или домена;
· APPEND_WALLET_ACE — добавление записи ACL для wallet (хранилища сертификатов);
· REMOVE_WALLET_ACE — удаление записи ACL для wallet.
Пример использования
-- Выдача прав на подключение к хосту пользователю SCOTT
BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host => 'www.example.com',
ace => XS$ACE_TYPE(
privilege_list => XS$NAME_LIST('connect', 'resolve'),
principal_name => 'SCOTT',
principal_type => XS_ACL.PTYPE_DB
)
);
END;
Please open Telegram to view this post
VIEW IN TELEGRAM
Для чего он нужен
Основные процедуры
· SET_SQL_TRACE_IN_SESSION — включение/выключение SQL-трассировки в указанной сессии ;
· KSDWRT — запись сообщения в alert-лог и/или файл трассировки ;
· SET_EV — установка трассировки для определённого события ;
· READ_EV — проверка, выполняется ли трассировка указанного события ;
· KSDIND — установка уровня отступа для вывода в файл трассировки ;
· KSDDDT — вывод информации о дате и времени в файл трассировки ;
· KSDFLS — сброс буфера вывода в файл трассировки ;
· DIST_TXN_SYNC — синхронизация распределённых транзакций (вызывается XA-библиотекой) .
Пример использования
-- Включение SQL-трассировки в другой сессии
EXEC DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(sid => 31, serial# => 97, sql_trace => TRUE);
-- Выключение трассировки
EXEC DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(31, 97, FALSE);
-- Запись сообщения в alert-лог
-- 2 — alert-лог, 1 — trace-файл, 3 — оба
EXEC DBMS_SYSTEM.KSDWRT(2, 'Тестовое сообщение');
Please open Telegram to view this post
VIEW IN TELEGRAM
Дорогие подписчики!
➡️ Продолжаем добавлять пакеты для PL/SQL-совместимости Digital Q.DataBase. Очередной — UTL_GDK (Globalization Development Kit).
Для чего он нужен
➡️ Пакет предоставляет функции для работы с локалями и преобразования имён языков, территорий и кодировок между различными стандартами: Oracle, IANA, ISO . Это полезно при разработке многоязычных приложений.
Основные функции
· charset_map — преобразование имени кодировки между стандартами Oracle и IANA ;
· language_map — преобразование названия языка между стандартами Oracle и ISO ;
· territory_map — преобразование названия территории между Oracle и ISO A-2 / A-3 .
Пример использования
Для чего он нужен
Основные функции
· charset_map — преобразование имени кодировки между стандартами Oracle и IANA ;
· language_map — преобразование названия языка между стандартами Oracle и ISO ;
· territory_map — преобразование названия территории между Oracle и ISO A-2 / A-3 .
Пример использования
-- Преобразование IANA-кодировки в Oracle
SELECT utl_gdk.charset_map('iso-8859-p1', utl_gdk.IANA_TO_ORACLE) FROM dual;
-- Результат: WE8ISO8859P1
-- Преобразование названия языка Oracle в ISO-код
SELECT utl_gdk.language_map('english', utl_gdk.ORACLE_TO_ISO) FROM dual;
-- Результат: en
-- Преобразование кода территории ISO в название Oracle
SELECT utl_gdk.territory_map('us', utl_gdk.ISO_TO_ORACLE) FROM dual;
-- Результат: America
Please open Telegram to view this post
VIEW IN TELEGRAM
1 5 3 2
Forwarded from DiasoftNews_channel
Подтверждена совместимость ОС "Альт Сервер" от "Базальт СПО" с СУБД Digital Q.DataBase компании Диасофт 🙌
Диасофт и "Базальт СПО" (мировой производитель системного программного обеспечения на базе собственной платформы разработки) подтвердили совместимость операционной системы "Альт Сервер" с системой управления базами данных (СУБД) Digital Q.DataBase.
💌Корректность работы подтверждена двусторонним сертификатом совместимости. Совместное использование "Альт Сервер" и Digital Q.DataBase создает гибкую, безопасную и масштабируемую платформу, готовую к эксплуатации в организациях с высокими требованиями к надежности и производительности.
Диасофт и "Базальт СПО" (мировой производитель системного программного обеспечения на базе собственной платформы разработки) подтвердили совместимость операционной системы "Альт Сервер" с системой управления базами данных (СУБД) Digital Q.DataBase.
💌Корректность работы подтверждена двусторонним сертификатом совместимости. Совместное использование "Альт Сервер" и Digital Q.DataBase создает гибкую, безопасную и масштабируемую платформу, готовую к эксплуатации в организациях с высокими требованиями к надежности и производительности.
Please open Telegram to view this post
VIEW IN TELEGRAM