СУБД SoQoL

Мы есть на карте Россия, как и другие современные государства, стремится к цифровой трансформации в различных областях, включая государственные услуги, здравоохранение, финансы и другие. И рынок IT-продуктов в России демонстрирует стабильный и динамичный рост. Компании в этой области и других смежных областях активно развиваются. Наше государство известно своими технологическими университетами и кадровым потенциалом в области IT (ну про Воронеж мы недавно рассказывали). Наши специалисты в области программирования, анализа данных, искусственного интеллекта и других сфер высокотехнологичной индустрии востребованы как внутри страны, так и за рубежом. Правительство России активно поддерживает развитие IT-отрасли через различные программы, субсидии и инвестиции в инновационные проекты. И сегодня в России наблюдается увеличение числа IT-стартапов и инновационных проектов. Крупные города, такие как Москва, Санкт-Петербург, Казань, Новосибирск и другие, становятся центрами технологического предпринимательства. Аналитический центр TAdviser выпустил новую инфографику «Карта российского рынка программного обеспечения», на которой отметил российских вендоров ПО. На карту включены свыше 300 отечественных разработчиков программного обеспечения (и мы там есть :)). Все они были распределены по 27 категориям в трех основных разделах: инфраструктурное ПО, прикладное ПО и информационная безопасность. В целом, IT-рынок в России претерпевает положительное развитие, и страна продолжает укреплять свою позицию как важный игрок в мировой IT-индустрии. P.S. РЕЛЭКС нашли? :)

СУБД SoQoL разрабатывается уже около семи лет, но это молодой продукт. И конечно, в текущей версии он уступает по функционалу более развитым системам. А разве кто-то видел продукт, в котором появилось всё и сразу? Для этого есть планы (в них озвученное уже есть :) ).   «Какие варианты использования СУБД есть?»   У нас в разработке несколько вариантов лицензирования, в том числе, позволяющих пользоваться СУБД бесплатно (для частного использования в тестах и в учебных заведениях). «Молодцы!» «Наконец-то, дождались! Хоть вижу и не всё в новой СУБД, что хотелось, но считаю, это уже прогресс.» «Не каждый на такой шаг осмелиться, тем более среди коммерсов! Разработчики Релэкс молодцы. Успехов вам!»   Благодарим всех и каждого и за критику, и за вопросы, и за поддержку! Мы понимаем, релиз — не пункт назначения, а только точка в длинном пути.   Пишите всё, что вас волнует касательно СУБД: - под постами этого канала (или в его чате); - сюда — в телеграмм-бот технической службы компании РЕЛЭКС   P.S. Для персонального использования можно, как всегда, скачать «свежую» сборку СУБД SoQoL здесь. Если хочется попробовать SoQoL без установки на свой компьютер, то это можно сделать на сайте SQLize Online. За эту возможность отдельная благодарность Вячеславу @srozhnev

Обратная связь   После релиза SoQoL было множество комментариев и вопросов (отдельное спасибо каждому!). Хотим по некоторым вопросам пройтись ещё раз   «Вряд ли новая СУБД написана с нуля, тем более частной компанией. Ну нет у частников таких ресурсов и времени. Скорее всего скрывают, что копия с Postgres»   Потоки информации растут постоянно, а архитектуры старых СУБД к этому просто не готовы. Можно придумывать всё новые фичи, делать «надстройки», но перемены нужны более фундаментальные. У нашей команды за плечами уже есть созданное семейство СУБД и большой опыт в разноплановых разработках, поэтому семь лет назад мы задумались над вопросом архитектуры существующих СУБД и начали с малого — с исследования. Постепенно маленькая идея превратилась в амбициозный план создания новой современной системы управления базами данных. У нас есть знания структур, правил и алгоритмов построения больших систем — это отличный способ применить свои знания на практике. Первые эмоции от разработки СУБД были смешанными: радость от возможности творить и создавать что-то новое смешивалась с разочарованием от неудач и ошибок. Но каждая ошибка — урок, каждое исправление — шаг к совершенству. И да, наша команда не такая большая, как хотелось бы, путь создания СУБД долгий и трудный, но нас заряжает, собирает вместе и ведёт вперед одна общая прекрасная цель — современная СУБД, отвечающая потребностям пользователей.   «Лично я сталкивался с Линтер до 2000го года. Т.е. если ядро не переписали с нуля, а использовали старое, то как минимум 20-ть лет СУБД есть. О какой новизне разработки может идти речь?»   Действительно, продуктам семейства ЛИНТЕР уже более 30 лет. Имя семейства употребляется и в полном наименовании новой СУБД — СУБД ЛИНТЕР SoQoL, что и смутило некоторых читателей статей и обзоров новой СУБД. Однако, в SoQoL, кроме семейной части названия, ничего от ЛИНТЕР нет. «Почему новая СУБД с закрытым кодом? Вы что-то скрываете? Боитесь развития? Сделайте как нормальные — опенсорс и будет всем счастье»   Эту тему, как философию, можно обсуждать долго. И у опенсора, и у проприетарного продукта есть свои поклонники и противники. Open source позволяет сообществу разработчиков работать вместе над улучшением программного обеспечения, но это не всегда гарантирует техническую поддержку и обновление продукта. Да и у разных веток самостоятельного развития могут возникнуть проблемы совместимости. Open source — один из инструментов, но не единственный. Владелец проприетарного программного обеспечения имеет полный контроль над разработкой, обновлениями и поддержкой продукта, что может обеспечить более стабильное и надежное его функционирование. И многие проприетарные программные продукты предлагают профессиональную техническую поддержку (а это плюс для быстрого решения проблем и вопросов пользователей). Плюсы и минусы есть у каждого подхода, поэтому многие крупные продукты включают в себя и открытые и проприетарные компоненты. И мы не против open source, мы за гармоничное развитие. Позже и в SoQoL планируется часть компонентов сделать открытыми, а часть оставить проприетарными. Наше мнение, что качественное развитие IT-сферы невозможно как без хорошего open source, так и без хороших продуктов с закрытым кодом.   «Осталось дождаться, когда 1С включит SoQoL в список поддерживаемых СУБД»   Эта тема поднимается периодически, и мы только за такой ход событий. Нам очень приятно, что пользователи задают такие вопросы. Для развития совместного сотрудничества с 1C должно исходить желание и от производителей 1С. Пользователи могут ускорить это процесс — своими обращениями в 1С с просьбой о совместимости с Соколом. Мы такой запрос в 1С отправляли :)   «Планируете получать сертификат ФСТЭК? СУБД аккредитована под гос. учреждения? А то некоторые СУБД уже давно набили оскомину»   В настоящий момент СУБД SoQoL включена в реестр российского ПО и этого достаточно для использования в некоторых гос. учреждениях. Сертификация ФСТЭК стоит у нас в плане.   «Ой насмешили. Прям СУБД. Да она ж сырая — оконных функций нет, триггеров нет, горячего резерва тоже. Что смотреть то?»

Поздравляем всех девушек с этим прекрасным весенним праздником!🌹

Опубликовали на Хабре небольшую обзорную статью о SoQoL. https://habr.com/ru/articles/797279/

Ура! Релиз СУБД SoQoL! Знаем, что многие из вас этого очень ждали. И мы очень старались сделать это в феврале. И сделали. Ряд внутренних процедур не позволил нам сказать об этом раньше, но сейчас мы готовы об этом сообщить. Первый релиз СУБД SoQoL теперь в вашем распоряжении! Первый релиз! Что это значит? Это значит, что впереди новый путь, который нам предстоит пройти вместе. Мы знаем, что еще много чего не сделали. И знаем, что есть то, о чём мы ещё не знаем и не сделали 🙂 Ну и немного информации для тех, кто мало знает о СУБД SoQoL. SoQoL — это инновационная российская СУБД, созданная с нуля на основе новейших достижений, потребностей рынка, глубоких научных знаний и богатого опыта команды компании РЕЛЭКС в области разработки как системного, так и прикладного программного обеспечения. Архитектура СУБД SoQoL отличается от всех ранее известных. Она основана на синтезе современных неблокирующих подходов обработки данных в памяти и работе с данными на внешних носителях, эффективном использовании кэша и адаптивности системы исполнения запросов. СУБД SoQoL не имеет ограничений специализированных СУБД и: · работает с большими дисковыми массивами данных; · реализует все требования ACID без исключений; · предоставляет различные уровни изоляции транзакций; · и конечно же, поддерживает хорошо знакомый пользователям стандарт ANSI SQL. Кластерные индексы, отсутствие потерь переключения контекста между исполнением SQL и кода хранимых процедур и многое другое — это всё тоже про новую СУБД. В СУБД SoQoL заложена кроссплатформенность, работа в различных операционных системах и аппаратных средах, включая российские. При разработке использовались собственные запатентованные методы обработки данных. СУБД SoQoL представляет собой транзакционную систему управления базами данных с производительностью, кратно превосходящей ведущие системы, как на рынке России, так и за его пределами. Лицензионные соглашения СУБД SoQoL позволяют ее использовать как в коммерческих целях (платное использование), так и в демонстрационных (включая разработку) или учебных (бесплатные варианты использования). Узнать больше о продукте можно на (обновленном) сайте СУБД SoQoL https://soqol.ru/ или в нашей группе https://t.me/soqol_dbms Мы понимаем, что процесс интеграции с вашими продуктами принесет нам много обратной связи (ну вы понимаете, о чем мы 🙂). Ждем ее с нетерпением. Но какие бы сложности не ждали нас на пути, мы справимся, потому что видим, что вы в нас верите и поэтому мы сильны!

Поздравляем всех защитников данных!

Вы вероятно заметили, что у нас небольшое затишье с постами. И это неспроста — все силы уходят на подготовку к первому релизу SoQoL. А мы тем временем продолжим наше небольшое отступление. Это третий и последний пост, который мы посвящаем краткой истории реляционных СУБД, разработанных нашей компанией в Воронеже. Мы закончили на том, что в 1990 году появляется Научно-производственное предприятие «Реляционные экспертные системы» или сокращенно РЕЛЭКС. В стенах новой компании стартует работа над системой, которая должна стать лучше СУБД ИНТЕРЕАЛ. (Обратили внимание на Лучше ИНТЕРеал? ) Ее пишут на Turbo Pascal под компьютерные платформы VAX и PDP. Так появляется первая версия российской СУБД ЛИНТЕР. Важным толчком к развитию ЛИНТЕР стал выход на зарубежный рынок и первые заказы из стран Северной Америки. СУБД полностью переписывается на языке Си, внедряется поддержка стандарта SQL. К 1994 году ЛИНТЕР уже поддерживает работу в Unix-системах реального времени USIX и OS-9. В 1995 году на базе ЛИНТЕР по заказу Главного управления по борьбе с организованной преступностью МВД России РЕЛЭКС разрабатывает информационно-аналитическую систему АСКРИН. В следующем году выходит новый продукт с ЛИНТЕР — ИАС «Невод». В 1996 году ЛИНТЕР получает сертификат Государственной комиссии при Президенте РФ на соответствие системы второму классу защиты информации от несанкционированного доступа. В 2001 году ЛИНТЕР — это лучший отечественный программный продукт по версии журнала «Компьютер Пресс» (кто такой помнит и читал?). А в 2002 году компания выводит СУБД на японский рынок, где система до сих пор применяется в IoT. РЕЛЭКС разрабатывала и другие варианты средств для работы с данными — Linter Micro, Linter Embedded, Semantic DB, Линтер-ВС (1.0), ББДРВ, Линтер-АСТИ. Но ключевым продуктом всегда оставалось семейство СУБД ЛИНТЕР. К 2010 ЛИНТЕР - это кроссплатформенная система, работающая на всех основных аппаратных и программных платформах. В 2016 году, в рамках исследовательских работ, появляется идея о создании нового ядра СУБД, в основу которого будут заложены современные подходы к разработке ПО с учетом максимально эффективного использования аппаратных ресурсов. Так появляется проект, с кодовым именем VIA (да, «через» это название мы должны были прийти к новому и тогда еще неизвестному). Через несколько лет появляется платформа, на основе которой разрабатывается СУБД SoQoL. И это уже новый виток истории в развитии продуктов семейства ЛИНТЕР.

Привет! Продолжаем наше историческое отступление о том, как в Воронеже разрабатывали реляционные СУБД. Следующая СУБД, после озвученных здесь, была разработана в СКТБ «Системпрограмм» к 1986 году. Назвали ее ИНТЕРЕАЛ (от «интерфейс реляционный»). В отличие от БАРС это уже было кроссплатформенное решение или, как тогда называли, мобильная СУБД. Ее особенность заключалась в возможности работы на ряде программно-аппаратных платформ: Электроника-82, Электроника-85, управляющие модули на базе Intel 8086, вычислительные комплексы на базе СМ-1420, СМ-1702, СМ-1810, СМ-1820 и их прототипы семейства VAX. Кстати, на воронежском заводе «Процессор» тогда выпускались компьютеры Электроника-85. В ИНТЕРЕАЛ были реализованы следующие технические решения: – CALL-интерфейс; – процессор операций с битовыми векторами; – аппарат квантования времени исполнения запросов; – диспетчеризация внутрисистемных очередей и ресурсов. СУБД обеспечивала многотерминальный и многозадачный доступ к базе данных. Манипулирование данными выполнялось с помощью непроцедурного языка ИНТТЕРМ, основанного на конструкциях языка QUEL. Присутствовал табличный экранный язык ИНТТАБ и процедурный язык командных файлов ИНТКОМ, который позволял создавать на основе БД прикладные системы. ИНТЕРЕАЛ использовали в: – информационно-поисковых системах, – системах управления технологическими процессами, производствами и управленческой деятельностью. К концу 1980-х годов финансирование системных разработок в стране практически прекращается. Дальнейшие работы по развитию воронежских СУБД в рамках государственного предприятия не представляются возможными. На этом история воронежских СУБД могла закончиться, но... В 1990 году, чтобы не потерять уникальный опыт и продолжить развитие отечественных СУБД, Бойченко Игорь Алексеевич (руководитель проектов СУБД БАРС и ИНТЕРЕАЛ) с командой создают частную компанию — кооператив (да, так они назывались в СССР). Так родилось Научно-производственное предприятие "Реляционные экспертные системы" или НПП "РЕЛЭКС". В его стенах (хотя в начале стен особо и не было) создаются новые решения, о которых расскажем в следующем посте. Продолжение следует...

Всем привет! В начале года хотим немного рассказать о том, как в Воронеже появились первые реляционные СУБД и наша компания. Это будет серия постов, в которых расскажем о продуктах, над которыми работал коллектив нашей компании до ее создания в 1990 г. и после до появления SoQoL Все началось давно… Где-то в конце 1970-х годов специальное конструкторско-технологическое бюро «Системных программных средств» получает заказ от правительства на разработку реляционной СУБД. В Воронеже тогда была хорошая математическая школа при Воронежском государственном университете. Кроме хорошей математической базы у команды была уверенность в возможность разработки собственной СУБД. В 1983 году выходит СУБД БАРС — базовая система для создания и ведения в реальном масштабе времени локальных баз данных реляционного типа. В СУБД БАРС пользователи могли параллельно осуществлять взаимодействие с несколькими локальными базами данных в соответствии с реляционной моделью. Данные внутри таблиц могли быть символьного, целого и вещественного типов. Была также предусмотрена возможность работы со строками символов различной длины. Система поддерживала многотомную структуру хранения, при которой БД может храниться на нескольких физических томах (например, магнитных дисках). Доступ к данным СУБД БАРС осуществлялся в диалоговом режиме с помощью специального непроцедурного языка манипулирования данными ЯНОТ. Запросы на языке ЯНОТ можно было включать в исходный код пользовательской программы, написанной на Макроассемблере, Фортране или Паскале. Для их обработки имелись предтрасляторы. Пользователи СУБД могли одновременно работать с нескольких терминалов независимо друг от друга. Для работы с СУБД БАРС требовались процессоры СМ-1420 или СМ-4, оперативная память минимум 56Кбайт (тогда это чаще называли как «28 Кслов»). СУБД функционировала в операционных системах РАФОС и РАФОС-2. БАРС использовали в: – АСУ различного назначения; – системах делопроизводства; – информационно-поисковых системах. Следующим этапом стала разработка, как тогда это называли, «мобильной» СУБД. Сейчас под словом «мобильный» понимается совсем другое, а тогда – это была возможность работы с разными процессорами и операционными системами. Продолжение следует... В первый комментарий добавить: Вот так выглядели компьютеры, на которых работала СУБД БАРС

Дорогие подписчики телеграм-канала СУБД SoQoL! Приближается весёлый праздник – Новый Год. Желаем, чтобы 2024-й стал для вас годом исполнения самых смелых целей, реализации заветных мечтаний! Пусть ваши проекты процветают, а каждый день приносит новые возможности и достижения! Пусть Новый год принесёт вам много радости, счастья и удачи, а команда разработчиков СУБД SoQoL всегда будет рядом! Спасибо вам за вашу верность и поддержку – мы ценим каждого! Желаем вам яркого и радостного Нового Года! С наступающим праздником!

Про ROUND   При работе с числовыми данными порой необходимо округлить суммы до определенного числа знаков после запятой. Особенно актуально это при работе с финансовыми расчётами.   Для упрощения этой операции во многих СУБД реализована функция ROUND. Посмотрим, есть ли отличия в реализации данной функции в Oracle 21, PostgreSQL 16, MS SQL Server 2022 и, конечно, в SoQoL.   Синтаксис ROUND (<x> [, <точность>]) подходит для всех озвученных СУБД, но в MS SQL Server 2022 он имеет более расширенную версию:

ROUND (<x> [, <точность>][, <тип_операции>])

  Где: - <x>  - исходное значение; - <точность> — точность округления в виде количества десятичных знаков до или после десятичной запятой. В случае MS SQL Server 2022 – это точность не только округления округления, но и усечения; - <тип_операции> - тип выполняемой операции, который зависит от указанного значения данного аргумента: если значение аргумента 0 (или значение аргумента отсутствует), то будет выполнено округление, а если это любое число – усечение.   Для значения точности также есть некоторые правила, и они общие для всех указанных СУБД: - значение точности должно быть задано целым числом, иначе значение точности будет автоматически усечено до целого; - если точность задана положительным числом, то это указывает на количество цифр после десятичной запятой, до которых необходимо выполнить округление, а если отрицательным числом - количество цифр перед запятой, которые необходимо округлить; - если точность задана положительным числом, превышающим количество цифр после десятичной запятой, то функция вернёт значение без изменений, а если отрицательным числом, превышающим количество цифр перед десятичной запятой – ноль; - если точность не указана, то исходное значение будет округлено до ближайшего целого числа;   Округляет, но по какому правилу?   Здесь всё тоже знакомо ещё со школьной математики: исходное значение будет округлено в большую сторону, если первая округляемая цифра больше или равна 5. В противном случае - в меньшую сторону. Такой метод ещё называют «стандартным математическим» и обычно он применяется во многих СУБД. Но если говорить об округлении более широко, то методов округления значительно больше. И кроме описанного «стандартного» метода округления, часто ещё применяются такие методы как: – «банковский метод округления чисел» – если число в десятичной части содержит 5, то оно округляется до ближайшей чётной цифры (например, 3,5 округляется до 4, а 2,5 до 2). Этот метод чаще всего применяют для минимизации погрешностей при расчётах в банковской сфере; – округление в сторону нуля, а по сути – усечение. Описанные методы можно, например, встретить в JDBC для некоторых СУБД, но это уже совсем другая история :)   А что с типами данных аргументов?   Значения аргументов должны быть числового типа, а в MS SQL Server 2022 функция ROUND также принимает аргументы типа MONEY и SMALLMONEY для округления денежных значений. В СУБД Oracle 21, PostgreSQL 16 и в SoQoL также допускаются: - значения строковых типов (CHAR, VARCHAR); - NULL. В первом случае будет выполнена попытка неявного преобразования значения к числовому типу, а во втором – результатом работы функции будет NULL. А вот для MS SQL Server 2022 в функции ROUND ни значения строковых типов, ни NULL недопустимы. В этих случаях работа функции будет завершена ошибкой. Таким образом, основной функционал ROUND в озвученных СУБД максимально схож. Отличается только MS SQL Server 2022. А в каких задачах вы используете методы округления? Каким чаще всего пользуетесь и почему?

Ряд символов, выстроенных в ряд, становятся строкой   Как мы уже начали говорить ранее, в каждой СУБД реализованы несколько типов данных. Только бывает так, что имена типов одинаковые, а «начинка» разная, или наоборот. Давайте сегодня посмотрим на строковые типы данных в наиболее распространённых СУБД и в SoQoL. Для сравнения мы взяли PostgreSQL, Oracle, MySQL, MS SQL Server:   1. Строка фиксированной длины • PostgreSQL 16: типы данных CHAR (size), CHARACTER (size), где size обозначает количество символов. Максимальный размер строки составляет 1 ГБ; • Oracle 21: типы данных CHAR (size), NCHAR (size). Здесь size для первого типа рассматривается в семантике байт, а для второго типа – в семантике символов. Максимальный размер для двух типов – 2000 байт; • MySQL 8.0: типы данных CHAR (size), где size обозначает количество символов. Тип может хранить до 255 байт; • MS SQL Server 2022: тип CHAR(size), NCHAR(size). Здесь size обозначает количество байт. Максимальный размер - 8000 байт. Значение size во всех случаях задаётся натуральным числом. И в случае всех рассмотренных СУБД значения указанных типов данных дополняются пробелами до указанного size. Однако, при сравнении двух значений, например, в PostgreSQL 15 дополняющие пробелы игнорируются, в Oracle же они учитываются. Что с типом CHAR в SoQoL скажем в следующем пункте.   2. Cтрока переменной длины • PostgreSQL16: типы данных VARCHAR (size), CHARACTER VARYING (size), где size обозначает количество символов. Максимально возможный размер строки составляет 1 ГБ; • Oracle 23: типы данных VARCHAR (size), VARCHAR2 (size), NVARCHAR2 (size). Здесь size, также как и в строках фиксированной длины, для первых двух типов рассматривается в семантике байт, а для NVARCHAR2 – в семантике символов. Максимальный размер – 4000 байт; • MySQL 8.0: VARCHAR(size), где size обозначает количество символов. Максимальный размер - 65 535 байт; • MS SQL Server 2022: VARCHAR(size), NVARCHAR(size), VARCHAR(max), NVARCHAR(max). Здесь size обозначает количество байт. Максимально возможный размер строки в первом и втором случае составляет 8000 и 4000 символов соответственно. Для остальных типов, в качестве размера которых указано max, максимальный размер - 2 Гб А что в SoQoL? В SoQoL реализованы типы данных CHAR (size), VARCHAR (size), VARCHAR2 (size). В текущей версии СУБД все три типа данных реализованы одинаково – как VARCHAR (size), где size обозначает количество байт. Максимальный размер составляет – 4000 байт. Как писали в предыдущей публикации – позже в SoQoL планируется тип CHAR (size) довести до его классического вида (с дополнением пробелами до (size) и их учёте при сравнении), а также значительно увеличить максимальное ограничение длины строки.   3. Строка большой длины • PostgreSQL 16: тип данных TEXT. В документации указано «Ограничение по размеру строки не установлено». Максимально возможный размер строки составляет 1 ГБ. А по сути этот тип представляет собой синоним VARCHAR без указания размерности. Но говорят, проблемы начинаются с размера значения 600 Мб (знатоки PostgreSQL, поправьте, если это не так); • Oracle 21: тип данных LONG. Максимальный размер составляет 2GB; • MySQL 8.0: типы данных TEXT, MEDIUMTEXT, LONGTEXT. Максимальный размер 65Кб, 16Мб, 4Гб соответственно; • MS SQL Server 2022: типы данных TEXT, NTEXT. Максимальный размер первого типа составляет 2Гб, второго - 1Гб. В SoQoL строка большой длины - тип данных CLOB, максимальный размер которого составляет 2^64 байт. А может вы из опыта знаете ещё какие-то особенности рассмотренных типов данных в озвученных или других СУБД? Поделитесь

Когда неявное не становится явным Поговорим о типах преобразования значений одного типа в другой и отличается ли результат в разных СУБД. В каждой СУБД реализованы несколько типов данных для обеспечения универсальности, эффективности хранения и обработки информации. Например: – разные типы данных имеют разное ограничение по размерам и структуре, что позволяет более эффективно управлять памятью и ускорять выполнение запросов; – различные типы данных позволяют хранить информацию в разных форматах, от текстов до изображений, что обеспечивает гибкость в разработке приложений и систем; – возможность выбора типа данных позволяет более эффективно выполнять некоторые операции. При выполнении операций со значениями разных типов данных в СУБД может допускаться неявное преобразование. Например, при выполнении арифметических операций числовых значений со строковыми в большинстве СУБД произойдет неявное преобразование строки в число. Также во всех современных СУБД предусмотрено явное преобразование, когда пользователь сам указывает значение какого аргумента в значение какого типа необходимо преобразовать. Это позволяет управлять процессом преобразования и быть уверенным, что полученные значения соответствуют требуемым типам данных. Теперь посмотрим на простых примерах результаты этих операций в разных СУБД: Неявное преобразование

create table T (A varchar(2), B boolean, C boolean);
insert into T (B, C) values (true, '1');
insert into T (A) select B from T;
insert into T (A) select C from T;

– Oracle 23, PostgresSQL 15, SoQoL – демонстрируют в этом случае одинаковое поведение: значение типа boolean в строковом типе становится 'true', длина которого больше, чем varchar(2). Поэтому данное преобразование завершается ошибкой. В MySQL 8.0 или в MariaDB 10 значения BOOLEAN true и false хранятся как 1 и 0 соответственно. И если в этих СУБД мы выполним указанные примеры, то значение true превращается в значение '1', занимающим один символ. И здесь неявное преобразование будет выполнено успешно. Если же в качестве примера возьмём преобразование из varchar(5) в varchar(2), то поведение будет такое же как и в вышеупомянутых СУБД. Явное преобразование

create table T (B boolean);
insert into T values (true);
select cast (B as varchar (2)) from T;

В данном примере даже крупные игроки разошлись во мнении: – Oracle 23 – возвращает ошибку «Data value out of range» (в 21-й версии такой пример вообще было недопустимо выполнить, т.к. тип boolean использовался только в языке PL/SQL и попытка создать таблицу из примера в 21-й версии заканчивается ошибкой «invalid datatype»). А если в примере возьмём значения других типов и, например, выполним преобразование из строки в строку, то преобразование будет успешно выполнено с усечением до размера целевого типа. – PostgresSQL 15 – успешно преобразует исходное значение с усечением до размера целевого типа 'tr' В SoQoL указанный пример в первой реализации завершался ошибкой. Но мы переосознали подход и теперь придерживаемся принципа: «неявное преобразование допустимо только без усечений и потери точности, явное – допускает усечение и потерю точности». Итак: – явное преобразование всегда выполняется только при осознанном желании пользователя выполнить преобразование. Оно также может помочь избежать недопонимания и ошибок, связанных с автоматическим преобразованием типов данных; – неявное преобразование работает самостоятельно «без ценных указаний» на основе «заложенных внутри принципов», которые у многих СУБД схожи; – результаты преобразования одних и тех же значений явным и неявным способом отличаются. И здесь возникает вопрос... А что думаете вы – для каких типов и каких преобразований типов должно быть допустимо неявное преобразование? Или может быть вы придерживаетесь кардинальной позиции «неявное преобразование – это вселенское зло и его нужно изжить на корню»?🙂

Продолжаем про CONCAT   В прошлой публикации мы затронули тему работы функции CONCAT с типами CHAR / VARCHAR. А со значениями каких типов данных эта функция в СУБД SoQoL может работать ещё?   В SoQoL функция CONCAT неявно попытается привести к VARCHAR значения типов: - NUMBER; - BOOLEAN; - DATE; - TIMESTAMP; - BINARY; - VARBINARY.   Но если одно из объединяемых значений равно NULL, то и результатом будет NULL.   Можно на этом и закончить рассказ, но был вопрос «А что по BLOBам? В текущей версии мы реализовали объединение значений этого типа с оглядкой на Oracle - отдельной функцией CONCAT_BLOB. Данная функция со значениями других типов не работает. А как объединяют значения типа BLOB другие СУБД? Postgres - оператор конкатенации Mysql - функция CONCAT и оператор конкатенации В будущем мы планируем добавить в функцию CONCAT возможность объединять и значения типа BLOB. Пока же среди членов нашей команды есть мнения за и против. Намекнём: например при разделении на разные функции CONCAT и CONCAT_BLOB можно по разному обрабатывать значения NULL в аргументах. А что думаете вы?

Классика не устаревает или кто-то просто отличился? Мы помним, что «по классике» CHAR — строковый тип фиксированной длины и если хранимые величины менее фиксированной длины типа, то они дополняются пробелами. VARCHAR — строковый тип переменной длины, в котором хранимые величины не дополняются пробелами. Эти два типа данных реализованы во всех популярных СУБД. В SoQoL они также реализованы, но в текущей версии CHAR пока представлен как синоним VARCHAR. А как эти типы реализованы в других СУБД? Посмотрим подробнее, как проявляется разная реализация типов CHAR / VARCHAR при работе с: - функцией concat; - операцией конкатенации «||».   Для начала рассмотрим самый распространённый случай, когда имя и фамилию нужно объединить в одну строку:  

create table WORKS (NAME varchar (15), SURNAME varchar (25));
insert into WORKS values ('Иванова', 'Мария');

  1. С функцией это будет выглядеть так:

select concat (NAME, concat (' ', SURNAME)) as FULLNAME from WORKS;

  2. При операции конкатенации:

select NAME || ' ' || SURNAME as FULLNAME from WORKS;

  В обоих случаях получаем в результате строку 'Иванова Мария' И так работает во многих известных СУБД.   Но этот простой и наглядный пример мы рассмотрели в случае, если объединяются значения типа VARCHAR. А теперь посмотрим пример с его собратом – типом CHAR, и тут история будет интереснее.   Возьмём для примера похожую таблицу, но заменим в ней VARCHAR на CHAR и посмотрим поведение в разных СУБД:  

create table TEST (SAY1 char (15), SAY2 char (25));
insert into TEST values ('ФА', 'СОЛЬ');

  1. select concat (SAY1, SAY2) from TEST;   Результаты: - SoQoL: 'ФАСОЛЬ' - Oracle: 'ФА              СОЛЬ                        ' - PostgreSQL 15: 'ФА              СОЛЬ                        ' - MySQL 8.0: 'ФАСОЛЬ' 2. select SAY1 || SAY2 from TEST;   Результаты: - SoQoL: 'ФАСОЛЬ' - Oracle: 'ФА              СОЛЬ                        ' - PostgreSQL 15: 'ФАСОЛЬ' Функция CONCAT эквивалентна операции конкатенации, но результат мы видим – разный. В чём «соль»? Если рассуждать логически... Значения типа CHAR дополняются пробелами до его зафиксированного размера. И их (пробелы) необходимо учитывать при работе со значениями типа CHAR. Такую позицию и показывает Oracle в обоих случаях. Но куда mysql дел дополненные пробелы типа CHAR? Или в mysql CHAR = VARCHAR? И почему Postgres показывает разное поведение при объедении значений CHAR с помощью функции CONCAT и операции конкатенации? SoQoL показывает одинаковое поведение и в последующем мы хотели тип CHAR доработать до его «классического» представления. Но теперь призадумались – а нужно ли? Кто-то пользуется ещё типом CHAR или из этих двух братьев достаточно только VARCHAR? Что скажете, опытные пользователи СУБД?

Всем привет! Нужно ваше экспертное мнение До 24 ноября АНО «Цифровая экономика» проводит опрос пользователей СУБД, имеющих практический опыт их эксплуатации. Всего четыре вопроса, несколько минут вашего времени, и всем это позволит получить объективную картину представленных СУБД в России. АНО «Цифровая экономика» пришлёт результаты опроса всем проголосовавшим! Ссылка на опрос https://forms.yandex.ru/cloud/65290571c417f373b5f5e991/

Повторные измерения, сделанные на основе предложенных нашими читателями параметров запуска двух СУБД. Детали в комментариях. Вам есть что сказать/спросить?

РЕЛЭКС в ТОП-10 рейтинга компаний, осуществляющих заказную разработку ПО, от CNews! 🧩 Занимаем место рядом с другими лидерами IT-рынка — рады! 🤩 Смотрите полный список компаний по ссылке.