Forwarded from Diasoft о технологиях по-настоящему
This media is not supported in your browser
VIEW IN TELEGRAM
1
Forwarded from Diasoft о технологиях по-настоящему
⚡️День СУБД ➡️ Анонс RuDB
Диасофт (производитель российской СУБД Digital Q.DataBase) и НППКТ (производитель СУБД Лира-Р и ОС Основа) совместно учредили Ассоциацию разработчиков СУБД. В рамках ассоциации была выпущена первая версия российской национальной СУБД RuDB с открытым исходным кодом.
Факты об отечественной СУБД нового поколения:
🟣 она основана на PostgreSQL 18.2 и совместима с ним;
🟣 содержит необходимые доработки по информационной безопасности и выполнению требований ФСТЭК;
🟣 совместима с основными российскими бизнес-приложениями.
⚡️Предлагаем скачать бесплатный дистрибутив уже сейчас и призываем других разработчиков СУБД присоединиться к Ассоциации разработчиков RuDB!
Диасофт (производитель российской СУБД Digital Q.DataBase) и НППКТ (производитель СУБД Лира-Р и ОС Основа) совместно учредили Ассоциацию разработчиков СУБД. В рамках ассоциации была выпущена первая версия российской национальной СУБД RuDB с открытым исходным кодом.
Факты об отечественной СУБД нового поколения:
⚡️Предлагаем скачать бесплатный дистрибутив уже сейчас и призываем других разработчиков СУБД присоединиться к Ассоциации разработчиков RuDB!
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Развенчиваем миф о пределе в 20ТБ при работе на PostgreSQL
Сегодня на совещании в одном из российских банков вновь услышали миф, что PostgreSQL «тормозит» на базах больше 20 ТБ.
Мол, "любой разумный человек должен понимать", что СУБД на базе PostgreSQL "не вывезет больше". Разумеется, это не более чем домыслы, которые легко опровергаются официальной документацией и реальными кейсами, как в РФ, так и за рубежом.
➡️ Официальные пределы:
Максимальный размер базы данных в PostgreSQL официально не ограничен. Есть только лимит на объём одной таблицы — 32 ТБ (и то его можно обойти, используя партиционирование). Сама СУБД спокойно оперирует сотнями терабайт и даже петабайтами.
➡️ Примеры из практики: от 150 ТБ до петабайт
🟣 ГИС ГМП (Россия) — Федеральное казначейство успешно перенесло с Oracle на PostgreSQL около 200 ТБ данных.
🟣 Сервис облачного мониторинга TigerData на базе PostgreSQL (TimescaleDB) хранит 350 ТБ данных и обрабатывает 1,5 триллиона метрик в день.
🟣 Yahoo! — построила на PostgreSQL репозиторий данных объёмом более 2 петабайт.
🟣 Так откуда же миф про 20 ТБ и почему он так живуч?
Вероятнее всего, есть путаница с лимитом PostgreSQL на одну таблицу. Путают размер базы (который ограничен лишь доступными ресурсами для хранения) и максимальный объём на таблицу, точнее один её сегмент (32 ТБ). И мол «надо же оставить запас на рост» — поэтому пусть будет 20 ТБ, а не 32.
А возможно, причина в том, что обслуживать базу в 150+ ТБ традиционными методами действительно непросто. Например, никакого разумного времени не хватит, чтобы создать или восстановить бэкап такой базы стандартным образом. Но это не проблема PostgreSQL — это особенность больших данных. В таких случаях используют специальные решения: реплики в режиме горячего резерва, stage-in, инкрементальные бэкапы и WAL-архивацию.
Итого: PostgreSQL и ряд основанных на этом проекте других СУБД, без проблем держат сотни терабайт и даже петабайты. Вопрос лишь в грамотной архитектуре и правильных подходах к эксплуатации.
Сегодня на совещании в одном из российских банков вновь услышали миф, что PostgreSQL «тормозит» на базах больше 20 ТБ.
Мол, "любой разумный человек должен понимать", что СУБД на базе PostgreSQL "не вывезет больше". Разумеется, это не более чем домыслы, которые легко опровергаются официальной документацией и реальными кейсами, как в РФ, так и за рубежом.
Максимальный размер базы данных в PostgreSQL официально не ограничен. Есть только лимит на объём одной таблицы — 32 ТБ (и то его можно обойти, используя партиционирование). Сама СУБД спокойно оперирует сотнями терабайт и даже петабайтами.
Вероятнее всего, есть путаница с лимитом PostgreSQL на одну таблицу. Путают размер базы (который ограничен лишь доступными ресурсами для хранения) и максимальный объём на таблицу, точнее один её сегмент (32 ТБ). И мол «надо же оставить запас на рост» — поэтому пусть будет 20 ТБ, а не 32.
А возможно, причина в том, что обслуживать базу в 150+ ТБ традиционными методами действительно непросто. Например, никакого разумного времени не хватит, чтобы создать или восстановить бэкап такой базы стандартным образом. Но это не проблема PostgreSQL — это особенность больших данных. В таких случаях используют специальные решения: реплики в режиме горячего резерва, stage-in, инкрементальные бэкапы и WAL-архивацию.
Итого: PostgreSQL и ряд основанных на этом проекте других СУБД, без проблем держат сотни терабайт и даже петабайты. Вопрос лишь в грамотной архитектуре и правильных подходах к эксплуатации.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
К хорошему привыкаешь быстро и кажется будто так было всегда.
Но иногда полезно оглянуться назад и вспомнить какой была наша любимая СУБД в прошлом.
Давайте запустим нашу "машину времени" и сделаем несколько остановок в прошлом проекта PostgreSQL, ставшего основой для нашей СУБД Digital Q.DataBase. Поехали!
🕰️ Начало 2025 года:
PostgreSQL 17 работает сильно медленнее привычного. Не удивительно, ведь в нём ещё нет асинхронного I/O (AIO) для параллельного чтения.
Также в нем еще нет:
· виртуальных генерируемых столбцов;
· встроенной uuidv7();
· аутентификации через OAuth 2.0.
🕰️ 2023 год:
В PostgreSQL 15 еще нет пакетной вставки для FDW через COPY.
🕰️ 2022 год.
В PostgreSQL 14 еще нет:
· команды MERGE (условное обновление/вставка);
· сжатия TOAST через LZ4.
🕰️ 2019 год.
PostgreSQL 11 ещё не знает что такое:
· генерируемые столбцы;
· JSON PATH для jsonb;
· хранимые процедуры с транзакциями (только функции);
· JIT-компиляция запросов.
🕰️ 2018 год.
В PostgreSQL 10 еще нет хранимых процедур (CREATE PROCEDURE).
Есть только функции (CREATE FUNCTION). Управлять транзакциями изнутри логики нельзя.
🕰️ 2017 год.
В PostgreSQL 9.6 еще нет:
· логической репликации;
· декларативного секционирования (PARTITION BY).
🕰️ 2016 год.
PostgreSQL 9.5 еще не знает:
· параллельных запросов;
· синхронной репликации с несколькими узлами.
🕰️ 2014 год.
В PostgreSQL 9.3 еще нет:
· типа jsonb;
· команды ALTER SYSTEM (менять настройки без перезапуска сервера нельзя);
Также нет даже зачатков логической репликации данных.
🕰️ 2012 год.
PostgreSQL 9.1 еще не поддерживает JSON. Также в нем еще нет каскадной репликации.
🕰️ 2011 год.
В PostgreSQL 9.0 еще нет:
· знаменитого механизма расширений (CREATE EXTENSION);
· доступа к внешним данным (FDW) в привычном нам виде.
🕰️ 2010 год.
PostgreSQL 8.4 еще не имеет:
· потоковой репликации;
· встроенных средств для кластеров высокой доступности.
🕰️ 2009 год.
В PostgreSQL 8.3 ещё нет:
· оконных функций;
· поддержки Common Table Expression (включая рекурсивные запросы);
· доступа к данным из внешних источников.
🕰️ 2008 год.
В PostgreSQL 8.2 еще нет:
· полнотекстового поиска;
· GIN-индексов.
🕰️ 2005 год.
В PostgreSQL 8.0 еще нет:
· ролей (есть только пользователи и группы);
· двухфазных коммитов (2PC).
🕰️ 2001 год.
PostgreSQL 7.0 ещё не имеет:
· журнала предзаписи (WAL);
· VACUUM без блокировки всей таблицы;
· современного нам EXPLAIN.
🕰️ 2000 год (важная веха).
В PostgreSQL 6.5 еще нет встроенного языка PL/pgSQL. Он появится лишь в PostgreSQL 7.0.
А пока что функции пишутся только на C и "голом" SQL (без переменных, циклов и условий). Полноценной хранимой бизнес-логики нет.
🕰️ 1998 год.
PostgreSQL 6.4 ещё не поддерживает операторы EXCEPT и INTERSECT.
🕰️ 1997 год.
В PostgreSQL 6.2 еще нет триггеров и вложенных подзапросов (Subselects).
🕰️ 1995 год.
Проект называется Postgres95.
Имени «PostgreSQL» ещё нет.
🕰️ 1986 год.
В предшественнике PostgreSQL еще нет языка SQL 😀. Вместо него используется язык POSTQUEL.
🕰️ 1970 год.
Проект Ingres в Беркли — родоначальник всей линейки проектов, приведших к возникновению PostgreSQL, еще не начат.
Ну вот и всё. Наше путешествие во времени подошло к концу. Надеюсь, что Вам понравилась наша "машина времени"!
А теперь давайте вернёмся в настоящее и порадуемся тому, сколько всего умеет современный нам PostgreSQL и основанные на нем проекты.
И заодно оценим, как долго и терпеливо создавался каждый фрагмент функциональности этой удивительной СУБД.
Но иногда полезно оглянуться назад и вспомнить какой была наша любимая СУБД в прошлом.
Давайте запустим нашу "машину времени" и сделаем несколько остановок в прошлом проекта PostgreSQL, ставшего основой для нашей СУБД Digital Q.DataBase. Поехали!
🕰️ Начало 2025 года:
PostgreSQL 17 работает сильно медленнее привычного. Не удивительно, ведь в нём ещё нет асинхронного I/O (AIO) для параллельного чтения.
Также в нем еще нет:
· виртуальных генерируемых столбцов;
· встроенной uuidv7();
· аутентификации через OAuth 2.0.
🕰️ 2023 год:
В PostgreSQL 15 еще нет пакетной вставки для FDW через COPY.
🕰️ 2022 год.
В PostgreSQL 14 еще нет:
· команды MERGE (условное обновление/вставка);
· сжатия TOAST через LZ4.
🕰️ 2019 год.
PostgreSQL 11 ещё не знает что такое:
· генерируемые столбцы;
· JSON PATH для jsonb;
· хранимые процедуры с транзакциями (только функции);
· JIT-компиляция запросов.
🕰️ 2018 год.
В PostgreSQL 10 еще нет хранимых процедур (CREATE PROCEDURE).
Есть только функции (CREATE FUNCTION). Управлять транзакциями изнутри логики нельзя.
🕰️ 2017 год.
В PostgreSQL 9.6 еще нет:
· логической репликации;
· декларативного секционирования (PARTITION BY).
🕰️ 2016 год.
PostgreSQL 9.5 еще не знает:
· параллельных запросов;
· синхронной репликации с несколькими узлами.
🕰️ 2014 год.
В PostgreSQL 9.3 еще нет:
· типа jsonb;
· команды ALTER SYSTEM (менять настройки без перезапуска сервера нельзя);
Также нет даже зачатков логической репликации данных.
🕰️ 2012 год.
PostgreSQL 9.1 еще не поддерживает JSON. Также в нем еще нет каскадной репликации.
🕰️ 2011 год.
В PostgreSQL 9.0 еще нет:
· знаменитого механизма расширений (CREATE EXTENSION);
· доступа к внешним данным (FDW) в привычном нам виде.
🕰️ 2010 год.
PostgreSQL 8.4 еще не имеет:
· потоковой репликации;
· встроенных средств для кластеров высокой доступности.
🕰️ 2009 год.
В PostgreSQL 8.3 ещё нет:
· оконных функций;
· поддержки Common Table Expression (включая рекурсивные запросы);
· доступа к данным из внешних источников.
🕰️ 2008 год.
В PostgreSQL 8.2 еще нет:
· полнотекстового поиска;
· GIN-индексов.
🕰️ 2005 год.
В PostgreSQL 8.0 еще нет:
· ролей (есть только пользователи и группы);
· двухфазных коммитов (2PC).
🕰️ 2001 год.
PostgreSQL 7.0 ещё не имеет:
· журнала предзаписи (WAL);
· VACUUM без блокировки всей таблицы;
· современного нам EXPLAIN.
🕰️ 2000 год (важная веха).
В PostgreSQL 6.5 еще нет встроенного языка PL/pgSQL. Он появится лишь в PostgreSQL 7.0.
А пока что функции пишутся только на C и "голом" SQL (без переменных, циклов и условий). Полноценной хранимой бизнес-логики нет.
🕰️ 1998 год.
PostgreSQL 6.4 ещё не поддерживает операторы EXCEPT и INTERSECT.
🕰️ 1997 год.
В PostgreSQL 6.2 еще нет триггеров и вложенных подзапросов (Subselects).
🕰️ 1995 год.
Проект называется Postgres95.
Имени «PostgreSQL» ещё нет.
🕰️ 1986 год.
В предшественнике PostgreSQL еще нет языка SQL 😀. Вместо него используется язык POSTQUEL.
🕰️ 1970 год.
Проект Ingres в Беркли — родоначальник всей линейки проектов, приведших к возникновению PostgreSQL, еще не начат.
Ну вот и всё. Наше путешествие во времени подошло к концу. Надеюсь, что Вам понравилась наша "машина времени"!
А теперь давайте вернёмся в настоящее и порадуемся тому, сколько всего умеет современный нам PostgreSQL и основанные на нем проекты.
И заодно оценим, как долго и терпеливо создавался каждый фрагмент функциональности этой удивительной СУБД.
1
Сегодня в рубрике «выходного дня» хочу рассказать вам о ярком представителе класса HSAP (Hybrid Serving and Analytical Processing) систем управления базами данных - DingoDB.
Кстати, не путайте HSAP (свежую концепцию, придуманную в Поднебесной в 2020-х) и HTAP (придуманную Gatrner в 2014) - это не опечатка, а дальнейшая эволюция идеи гибридных СУБД.
Итак, DingoDB это китайская СУБД для Linux с открытой лицензией. Она умеет искать по смыслу. И использует для этого обычный SQL.
Представьте: у вас есть корпоративный архив — текстовые протоколы, аудиозаписи, видеоинструкции, сканы договоров. Надо найти всё, что по смыслу близко к фразе «как зарегистрировать предложение о доработке продукта?». Не тег, не ключевое слово — именно смысл документа является критерием поиска.
Обычные СУБД с этим не справляются. А вот HSAP-системы и, в частности, DingoDB — легко.
Любой контент (текст, звук, картинку) эта система превращает в вектор — «цифровой отпечаток» смысла. А дальше два простых SQL-запроса.
INSERT INTO documents (id, title, content_vector)
VALUES (1, 'Заголовок документа', TXT2VEC('Содержимое документа...'));
Функция TXT2VEC() сама создаёт вектор из текста. Также есть функции IMG2VEC() и AUDIO2VEC() для обработки изображений и аудиоконтента.
SELECT title FROM documents
ORDER BY VECTOR_DISTANCE(content_vector, TXT2VEC('как предложить доработку в продукт?'))
LIMIT 5;
Запрос вернёт самые близкие по смыслу документы, даже если там нет тех же слов. И даже если эти документы на другом языке.
SELECT * FROM documents
WHERE doc_type = 'audio' AND date > '2026-01-01'
ORDER BY VECTOR_DISTANCE(content_vector, TXT2VEC('что делать, если появилась идея по развитию продукта'))
LIMIT 10;
Вот это и есть гибридный поиск: точные условия (WHERE) плюс смысловое ранжирование.
DingoDB — одна из первых СУБД класса HSAP. Она идеально подходит под RAG-приложения, корпоративные архивы, медиа-библиотеки.
Но заложенные в ней идеи проникли и в другие СУБД, в частности возможности по векторизации контента уже появились и в Oracle и в MS SQL.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Уважаемые коллеги!
28 апреля с 12:00 до 13:00 (МСК) компания «Диасофт» проведет вебинар на тему: «День СУБД: продолжение диалога». Продолжаем диалог о российских СУБД в формате Q&A.
На Дне СУБД 2026 возникло много вопросов, которые мы не успели разобрать. Приглашаем вас на закрытую онлайн-встречу, где вы можете задать вопросы о внедрении, миграции или производительности российских СУБД — мы дадим развернутый ответ. Вы можете заранее задать свои вопросы для вебинара перейдя по ссылке.
Подать заявку на участие в вебинаре можно до 27 апреля(включительно) здесь.
Пройдя регистрацию по этой ссылке, вы подтвердите свою заинтересованность в вебинаре.
Ссылку на страницу с трансляцией вебинара вы получите в день его проведения.
Участие в вебинаре – бесплатное. Регистрация – обязательна!
28 апреля с 12:00 до 13:00 (МСК) компания «Диасофт» проведет вебинар на тему: «День СУБД: продолжение диалога». Продолжаем диалог о российских СУБД в формате Q&A.
На Дне СУБД 2026 возникло много вопросов, которые мы не успели разобрать. Приглашаем вас на закрытую онлайн-встречу, где вы можете задать вопросы о внедрении, миграции или производительности российских СУБД — мы дадим развернутый ответ. Вы можете заранее задать свои вопросы для вебинара перейдя по ссылке.
Подать заявку на участие в вебинаре можно до 27 апреля(включительно) здесь.
Пройдя регистрацию по этой ссылке, вы подтвердите свою заинтересованность в вебинаре.
Ссылку на страницу с трансляцией вебинара вы получите в день его проведения.
Участие в вебинаре – бесплатное. Регистрация – обязательна!
Дорогие подписчики!
🟣 Продолжаем рассказывать о поддержке XML-методов в Digital Q.DataBase. Сегодня — о методе modify().
modify() — изменение XML-документов
🟣 Метод modify() позволяет изменять содержимое XML-документа непосредственно внутри базы данных. Поддерживаются вставка новых узлов, удаление существующих и замена значений.
⬇️ Пример использования:
⬇️ Основные возможности:
➡️ Вставка узлов (insert) с указанием позиции (as first, as last, before, after);
➡️ Замена значений (replace value of);
➡️ Удаление узлов (delete);
➡️ Изменение атрибутов элементов.
🟣 Хочу ещё раз напомнить: именно такая, пошаговая работа над совместимостью позволяет переходить на Digital Q.DataBase без переписывания прикладного кода. Все четыре XML-метода MS SQL Server — value, query, nodes и modify — теперь работают в нашей СУБД.
modify() — изменение XML-документов
-- Вставка нового узла
UPDATE employees_xml
SET xml_data.modify('insert <phone>123-4567</phone> as last into (/employee)[1]')
WHERE id = 1;
-- Замена значения узла
UPDATE employees_xml
SET xml_data.modify('replace value of (/employee/salary/text())[1] with 50000')
WHERE id = 1;
-- Удаление узла
UPDATE employees_xml
SET xml_data.modify('delete (/employee/old_field)[1]')
WHERE id = 1;
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Diasoft о технологиях по-настоящему
🏆 Диасофт участвует в премии ЦИПР Диджитал-2026 - голосование уже идет!
Премия отмечает значимые достижения в цифровой трансформации бизнеса и государства. Победителей объявят на конференции «Цифровая индустрия промышленной России», которая пройдет уже в мае.
В этом году мы представлены сразу несколькими проектами:
🔵 Платформа Digital Q в основе экосистемы Безопасный город
➡️ Голосовать
🔵 Построение платформы расчетных операций с цифровым рублем в Совкомбанке
➡️ Голосовать
🔵 Внедрение личного кабинета сотрудника в Диасофт
➡️ Голосовать
Будем рады вашей поддержке – каждый голос важен! 🙌
Премия отмечает значимые достижения в цифровой трансформации бизнеса и государства. Победителей объявят на конференции «Цифровая индустрия промышленной России», которая пройдет уже в мае.
В этом году мы представлены сразу несколькими проектами:
➡️ Голосовать
➡️ Голосовать
➡️ Голосовать
Будем рады вашей поддержке – каждый голос важен! 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
3
Если коротко, один и тот же подход закрывает сразу несколько задач.
Фиксируем состояние базы, поднимаем копию на целевой стороне и начинаем передавать изменения. Пока система работает, новая среда догоняет источник.
В момент переключения применяем дельту — и получаем минуты простоя вместо долгого окна.
Изменения из основной базы постоянно уходят во вторую среду. Это не обязательно синхронная репликация — можно накапливать и доставлять изменения.
В результате на резервной стороне всегда есть почти актуальное состояние, и восстановление — это переключение, а не восстановление «из вчера».
CDC выносит изменения из транзакционной системы в отдельный контур. Боевая база продолжает обслуживать нагрузку, а аналитика получает свежие данные без тяжёлых запросов в production. Фактически — разделение операционного и аналитического контуров без задержек в сутки.
Из разных источников (филиалы, сервисы, локальные базы) изменения стекаются в центральную точку.
Без пакетных выгрузок и ночных окон — данные приходят по мере изменений. Это упрощает мониторинг, отчётность и построение единой картины по бизнесу.
Один механизм, а сценарии — от миграции до построения целой архитектуры вокруг данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
🎉 Первомайское утро, День Весны и Труда, а у многих ассоциации только с шашлыками и выходными. Но для тех, кто живёт кодом и железом, 1 мая — это еще и двойной профессиональный праздник!
Сразу две памятные для ИТ-шников даты:
💻 1 мая 1969 года — дата создания компании AMD, их день рождения. С этого дня начался путь гиганта, чьи процессоры и видеокарты тащат все, что мы на них пробуем запускать.
🎨 Всемирный день перезагрузки CSS (CSS Reboot Day) — неофициальный, но полезный движ для веб-разработчиков. Суть: выкинуть легаси, навести порядок в стилях, переписать старые проекты под современные стандарты. Этакий digital-субботник, только без граблей.
Так что поднимайте бокал (или кружку с кофе) за труд, весну и технологии. Пусть Ваши процессоры не греются, Ваши сайты работают, а баги обходят Ваши проекты стороной!
Сразу две памятные для ИТ-шников даты:
💻 1 мая 1969 года — дата создания компании AMD, их день рождения. С этого дня начался путь гиганта, чьи процессоры и видеокарты тащат все, что мы на них пробуем запускать.
🎨 Всемирный день перезагрузки CSS (CSS Reboot Day) — неофициальный, но полезный движ для веб-разработчиков. Суть: выкинуть легаси, навести порядок в стилях, переписать старые проекты под современные стандарты. Этакий digital-субботник, только без граблей.
Так что поднимайте бокал (или кружку с кофе) за труд, весну и технологии. Пусть Ваши процессоры не греются, Ваши сайты работают, а баги обходят Ваши проекты стороной!
1
Основные вехи развития протокола:
Из последних нововведений (PostgreSQL 18):
Сжатие данных в протоколе — это функция, которую ждут многие и её реализация уже проработана до деталей: для включения сжатия в libpq достаточно указать опцию compression в строке подключения, а протокол для этого использует три новых типа сообщений: CompressionAck, CompressedData и SetCompressionMethod.
Реализация пока отсутствует в "ванильном" PostgreSQL, но уже есть в некоторых коммерческих СУБД на его основе.
Ожидается, что 4-ая версия протокола также привнесет новые инновации - с нетерпением ждем его обновления.
В любом случае, интересно наблюдать за развитием этого транспортного протокола.
Please open Telegram to view this post
VIEW IN TELEGRAM
Самый дорогой SQL-запрос в истории
Курьёзный факт:
В 2015 году инженер Amazon, тестируя новый код на одном из серверов платежной системы, забыл добавить WHERE к запросу на удаление. Вместо того чтобы удалить одну единственную тестовую запись, он выполнил DELETE всех записей из таблицы с информацией о платежах. Самый обычный DELETE без WHERE. И да - в боевой базе.
Результат:
Сразу несколько всемирно известных Интернет-сервисов на несколько часов потеряли возможность принимать платежи - просто потому, что восстановление огромной БД в предшествующее сбою состояние заняло значительное время.
Почему это занятно:
· Неверный запрос был длиной всего в 15 символов.
· Ущерб составил, по разным оценкам, от 50 до 100 миллионов долларов потерянной выручки.
· После этого в Amazon (и многих других крупных компаниях) запретили выполнять операторы DELETE и UPDATE без явного WHERE - добавили внутреннюю защиту в IDE.
🛡️Даже в популярном инструменте DBeaver теперь есть такая защита - при попытке выполнить подобный запрос Вас остановят вопросом осознаёте ли Вы все последствия выполнения команды DELETE или UPDATE без WHERE.
Желаем Вам, чтобы Ваши данные были в целости и сохранности и чтобы с ними никогда не приключилось подобной истории 🍀
Курьёзный факт:
В 2015 году инженер Amazon, тестируя новый код на одном из серверов платежной системы, забыл добавить WHERE к запросу на удаление. Вместо того чтобы удалить одну единственную тестовую запись, он выполнил DELETE всех записей из таблицы с информацией о платежах. Самый обычный DELETE без WHERE. И да - в боевой базе.
Результат:
Сразу несколько всемирно известных Интернет-сервисов на несколько часов потеряли возможность принимать платежи - просто потому, что восстановление огромной БД в предшествующее сбою состояние заняло значительное время.
Почему это занятно:
· Неверный запрос был длиной всего в 15 символов.
· Ущерб составил, по разным оценкам, от 50 до 100 миллионов долларов потерянной выручки.
· После этого в Amazon (и многих других крупных компаниях) запретили выполнять операторы DELETE и UPDATE без явного WHERE - добавили внутреннюю защиту в IDE.
🛡️Даже в популярном инструменте DBeaver теперь есть такая защита - при попытке выполнить подобный запрос Вас остановят вопросом осознаёте ли Вы все последствия выполнения команды DELETE или UPDATE без WHERE.
Желаем Вам, чтобы Ваши данные были в целости и сохранности и чтобы с ними никогда не приключилось подобной истории 🍀
1
Дорогие подписчики!
✅ Продолжаем рассказывать о доработках, вошедших в последний выпуск Digital Q.DataBase. Сегодня — о расширении поддержки динамических курсоров (dynamic cursor) в нашей реализации T-SQL-диалекта.
Что это даёт
✅ Динамические курсоры видят изменения данных, которые вносят другие пользователи уже после открытия курсора. Это важно для систем реального времени — операторских, диспетчерских, активно обновляемых таблиц.
Пример использования:
✅ Доступно в Digital Q.DataBase, начиная с версии от 21 марта.
Что это даёт
Пример использования:
DECLARE cur CURSOR DYNAMIC
FOR SELECT id, name FROM employees WHERE department_id = 10;
OPEN cur;
FETCH NEXT FROM cur;
WHILE @@FETCH_STATUS = 0
BEGIN
FETCH NEXT FROM cur;
END;
CLOSE cur;
DEALLOCATE cur;
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Уважаемые подписчики!
✅ В очередном обновлении Digital Q.DataBase мы продолжили работу над совместимостью со старыми версиями MS SQL Server в нашей реализации T-SQL-диалекта.
Кому это нужно
✅ Некоторые информационные системы были созданы ещё во времена MS SQL Server 6.5, 7.0 и 2000. Многие из них написаны на устаревших инструментах, таких как PowerBuilder, которые обращаются к системным представлениям и процедурам напрямую, используя специфические имена колонок и структуры, давно изменённые в более новых версиях.
При переходе на Digital Q.DataBase такие системы могли сталкиваться с ошибками.
Что сделано
✅ Доработан ряд системных представлений и хранимых процедур. Теперь они возвращают данные в формате, ожидаемом старыми приложениями, без необходимости переписывать код.
Кому это нужно
При переходе на Digital Q.DataBase такие системы могли сталкиваться с ошибками.
Что сделано
Please open Telegram to view this post
VIEW IN TELEGRAM
Как всё начиналось
Что сейчас
· тестируют Digital Q.DataBase в рамках своих внутренних информационных систем;
· готовят интеграцию СУБД в учебные процессы;
· планируют использовать наш готовый учебный курс по основам современных баз данных.
Что это даёт студентам
Что дальше
Если Вы или Ваши знакомые имеете отношение к высшему или профессиональному образованию — будем рады сотрудничеству.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Дорогие подписчики!
✅ В очередном обновлении Digital Q.DataBase внесены многочисленные правки в парсер для исправления синтаксических ошибок и корректной работы различных языковых конструкций в нашей реализации T-SQL-диалекта.
Что доработано:
· Конструкция
· Команды
· Синтаксис
✅ Доработки доступны в Digital Q.DataBase, начиная с версии от 21 марта.
Что доработано:
· Конструкция
INSERT INTO t (SELECT ... FROM ... ORDER BY ... OFFSET n ROWS);· Команды
ALTER TABLE ... ADD/DROP для случаев, когда в одном запросе фигурирует более одного столбца;· Синтаксис
EXEC.procedure_name.Please open Telegram to view this post
VIEW IN TELEGRAM
Дорогие подписчики!
Сегодня — 9 мая.
Поздравляем вас с Днём Победы.
Этот день — память о тех, кто защищал страну, кто работал в тылу, кто восстанавливал мирную жизнь. Низкий поклон ветеранам. Вечная память павшим.
Желаем вам мира, здоровья и спокойствия. Пусть в ваших домах всегда будет тепло и уютно.
С праздником!
Сегодня — 9 мая.
Поздравляем вас с Днём Победы.
Этот день — память о тех, кто защищал страну, кто работал в тылу, кто восстанавливал мирную жизнь. Низкий поклон ветеранам. Вечная память павшим.
Желаем вам мира, здоровья и спокойствия. Пусть в ваших домах всегда будет тепло и уютно.
С праздником!
5
«SQL Server» — название, которое не придумывали 🤔
Многие думают, что SQL Server — это целиком детище Microsoft. На самом деле история запутаннее.
🧩 В конце 80-х Microsoft, Sybase и Ashton-Tate совместно разрабатывают реляционную базу для OS/2. Код пишут в основном инженеры Sybase, поэтому продукт называется Sybase SQL Server. Microsoft выступает дистрибьютором и портирует его на свою платформу.
⚙️ В 1992 году Microsoft решает, что пора развивать собственный SQL Server. Партнёрство фактически разрывается, но… новой марки не придумывают. Вместо этого компания просто убирает слово «Sybase» и начинает выпускать Microsoft SQL Server 4.2 (версия берётся от последней совместной). И её код почти полностью совпадал с кодом Sybase SQL Server 4.2.
💼 В 1994 году Microsoft выкупила у Sybase права на этот код, и стороны официально прекратили партнёрство.
🚀 А в 1995 году вышел Microsoft SQL Server 6.0 — первая версия продукта без кода от Sybase.
Ирония: позднее Microsoft возьмёт реванш и обгонит Sybase по доле рынка, но историю с происхождением названия продукта ей уже не отменить. 😏
Многие думают, что SQL Server — это целиком детище Microsoft. На самом деле история запутаннее.
🧩 В конце 80-х Microsoft, Sybase и Ashton-Tate совместно разрабатывают реляционную базу для OS/2. Код пишут в основном инженеры Sybase, поэтому продукт называется Sybase SQL Server. Microsoft выступает дистрибьютором и портирует его на свою платформу.
⚙️ В 1992 году Microsoft решает, что пора развивать собственный SQL Server. Партнёрство фактически разрывается, но… новой марки не придумывают. Вместо этого компания просто убирает слово «Sybase» и начинает выпускать Microsoft SQL Server 4.2 (версия берётся от последней совместной). И её код почти полностью совпадал с кодом Sybase SQL Server 4.2.
💼 В 1994 году Microsoft выкупила у Sybase права на этот код, и стороны официально прекратили партнёрство.
🚀 А в 1995 году вышел Microsoft SQL Server 6.0 — первая версия продукта без кода от Sybase.
Ирония: позднее Microsoft возьмёт реванш и обгонит Sybase по доле рынка, но историю с происхождением названия продукта ей уже не отменить. 😏
🛡️ Ларри Эллисон против Билла Гейтса: когда СУБД объявила войну
1992 год. Oracle 7 — технологический прорыв: поддержка хранимых процедур, триггеров, ссылочной целостности. База становится серьёзным игроком в корпоративном сегменте.
И тут Ларри Эллисон замечает неприятный тренд: Microsoft и Sybase вместе разрабатывают SQL Server для OS/2 и Windows NT. Партнёрство грозит создать мощного конкурента прямо на десктопах.
Ларри принимает волевое решение: Oracle должна нанести упреждающий удар.
⚡️ Он публично бросает вызов Microsoft и лично Биллу Гейтсу. Лозунг: «NT — это несерьёзно». В ход идут статьи в прессе, сравнительные тесты (часто сомнительные) и жёсткая риторика. Эллисон называет Windows NT «игрушечной ОС» и продвигает Unix как единственную платформу для настоящих баз данных.
💥 Ответ Microsoft не заставил себя ждать: они скупают рекламные полосы в Wall Street Journal с заголовками «Oracle на NT работает быстрее, чем на Unix» — и приводят цифры независимых лабораторий. Начинается классический вендорский холивар, который длится годы.
📌 Итог: Oracle не смогла остановить SQL Server. Но эта война подстегнула обе компании — каждая из них стала резко улучшать производительность, масштабируемость и инструменты администрирования. Так что для пользователей СУБД эта конкуренция пошла лишь на пользу.
Кстати, "вендорские войны" между производителями СУБД идут прямо сейчас и в России. Возможно они также пойдут на пользу нашим отечественным СУБД.
1992 год. Oracle 7 — технологический прорыв: поддержка хранимых процедур, триггеров, ссылочной целостности. База становится серьёзным игроком в корпоративном сегменте.
И тут Ларри Эллисон замечает неприятный тренд: Microsoft и Sybase вместе разрабатывают SQL Server для OS/2 и Windows NT. Партнёрство грозит создать мощного конкурента прямо на десктопах.
Ларри принимает волевое решение: Oracle должна нанести упреждающий удар.
⚡️ Он публично бросает вызов Microsoft и лично Биллу Гейтсу. Лозунг: «NT — это несерьёзно». В ход идут статьи в прессе, сравнительные тесты (часто сомнительные) и жёсткая риторика. Эллисон называет Windows NT «игрушечной ОС» и продвигает Unix как единственную платформу для настоящих баз данных.
💥 Ответ Microsoft не заставил себя ждать: они скупают рекламные полосы в Wall Street Journal с заголовками «Oracle на NT работает быстрее, чем на Unix» — и приводят цифры независимых лабораторий. Начинается классический вендорский холивар, который длится годы.
📌 Итог: Oracle не смогла остановить SQL Server. Но эта война подстегнула обе компании — каждая из них стала резко улучшать производительность, масштабируемость и инструменты администрирования. Так что для пользователей СУБД эта конкуренция пошла лишь на пользу.
Кстати, "вендорские войны" между производителями СУБД идут прямо сейчас и в России. Возможно они также пойдут на пользу нашим отечественным СУБД.
Дорогие подписчики!
Сегодня — немного истории.
🟣 Знаете ли вы, что Microsoft SQL Server почти 30 лет (с 1987 по 2016 год) работал исключительно на Windows? Перелом случился только в 2016 году, когда Microsoft выпустила версию для Linux. Это не стало шоком для индустрии (ибо тот же Gartner предсказывал это в своих прогнозах еще года за 3 до того, как это произошло), но стало признанием того, что Linux постепенно становится основной операционной системой для серверов и, в частности, для СУБД.
А что Digital Q.DataBase?
🟣 Мы с самого начала создавали Digital Q.DataBase под различные операционные системы на базе Linux.
В настоящий момент наша СУБД работает на следующих операционных системах:
· Astra Linux Special Edition 1.7 и 1.8;
· РЕД ОС 7.3 и 8.0;
· ОС «Альт Сервер» 11;
· Ubuntu 22.04 LTS, 24.04 LTS.
🟣 На нашем сайте https://database.diasoft.ru/ Вы можете скачать бесплатно ту операционную систему, которая подходит именно Вам.
Сегодня — немного истории.
А что Digital Q.DataBase?
В настоящий момент наша СУБД работает на следующих операционных системах:
· Astra Linux Special Edition 1.7 и 1.8;
· РЕД ОС 7.3 и 8.0;
· ОС «Альт Сервер» 11;
· Ubuntu 22.04 LTS, 24.04 LTS.
Please open Telegram to view this post
VIEW IN TELEGRAM
→ Видео:
https://rutube.ru/video/e3922ad66b159f90bd991bf15f176025/
Please open Telegram to view this post
VIEW IN TELEGRAM