SQL Academy: всё о реляционных БД и SQL

Сможете отличить полезный ИИ-инструмент от очередного хайпа? 29 июня в 20:00 на открытом вебинаре рассмотрим современные ИИ-инструменты для разработчиков и практические сценарии их применения. В программе: • разбор решений для ускорения написания и отладки кода; • демонстрация инструментов генерации кода, тестов и документации; • кейсы использования LLM в повседневной разработке; • примеры внедрения ИИ в рабочие процессы и CI/CD-пайплайны. Вебинар поможет разобраться в возможностях современных ИИ-инструментов, понять, как использовать нейросети для рефакторинга и анализа кода, а также подобрать подходящие решения под свой стек технологий. Регистрация бесплатный на урок: https://tglink.io/6a441eb66fe4b0?erid=2W5zFGfJQQh Урок пройдёт в рамках старта курса «ИИ для разработчиков». Плавный старт курса продлится до 13.07.2026. Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🚀 Поздний JOIN: как ускорить OFFSET на больших данных в 10 раз Классическая пагинация через OFFSET сильно замедляет базу. Она читает тысячи тяжелых строк целиком только для того, чтобы их отбросить. 📉 В чём проблема 🔹 Представь поиск 100-й страницы в толстой энциклопедии. Вместо оглавления ты читаешь весь текст с первой страницы, пока не дойдёшь до сотой. 🔹 Так же делает база при OFFSET 100000: она собирает с диска все данные (длинные тексты, даты), отсчитывает ненужные сто тысяч строк и просто выбрасывает их. Это огромная трата ресурсов. 🚀 Решение — Поздний JOIN (Deferred Join) Сначала мы быстро находим нужные идентификаторы, а уже к ним присоединяем полные данные:

SELECT p.*
FROM (
    SELECT id FROM products
    ORDER BY price
    LIMIT 50 OFFSET 100000
) AS sub
JOIN products p ON p.id = sub.id;

⚙️ Как это работает 🔸 Внутренний запрос работает как оглавление. Он бежит только по легкому индексу (цене и id), мгновенно пропуская 100 тысяч записей, и выдает 50 нужных id. 🔸 Внешний JOIN обращается к самой таблице и загружает тяжелые данные только для этих 50 финальных строк. 💡 Этот контринтуитивный трюк спасет твою пагинацию, когда таблица огромная, а отказаться от навигации по номерам страниц нельзя.

📈 ClickHouse редко работает изолированно — в реальных проектах ему приходится взаимодействовать с базами данных, потоковыми системами, облачными хранилищами и инструментами визуализации. От того, насколько грамотно настроены эти интеграции, зависит скорость загрузки данных, качество аналитики и удобство работы пользователей. 📆 На открытом вебинаре разберём, как интегрировать ClickHouse с популярными внешними системами. Покажем подключение к PostgreSQL, настройку потоковой загрузки данных через Kafka, работу с S3 в качестве хранилища и построение аналитических отчётов в Superset. На практических примерах рассмотрим особенности каждой интеграции и сценарии их использования в современных аналитических платформах. 💡 Открытый вебинар пройдёт 23 июня в 20:00 МСК в преддверии старта курса «ClickHouse для инженеров и архитекторов БД». Участие бесплатное. Зарегистрироваться: https://otus.pw/v4QL/?erid=2W5zFJBiRJZ Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Бесплатный вебинар «Обзор инфраструктуры Ollama» 23 июня в 20:00 МСК . Все больше команд разворачивают ИИ-модели внутри своей инфраструктуры, чтобы защитить данные, снизить зависимость от внешних сервисов и сократить расходы на API. На занятии разберем: • как устроена платформа Ollama для локального запуска LLM; • установку и настройку на Linux, macOS и Windows; • работу с моделями: загрузку, запуск, управление версиями; • квантизацию и оптимизацию моделей для ограниченных ресурсов. После урока вы: • поймете архитектуру Ollama и принципы ее работы; • сможете развернуть локальную LLM без облачных зависимостей; • узнаете, как эффективно использовать вычислительные ресурсы и выбирать подходящие модели. Урок пройдет в рамках «курса ИИ для разработчиков» и будет полезен разработчикам, DevOps-инженерам и всем, кто изучает практическое применение ИИ. Регистрация: https://tglink.io/ddb03b4af97b0e?erid=2W5zFH1UJVF Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🔑 UUIDv4 тихо убивает твою базу UUID удобен: генерируешь на бэке, ключи уникальны, и никто не подсмотрит число заказов, поменяв цифру в URL. Кажется, идеальный Primary Key. Но обычный UUIDv4 — полностью случайный. А базе это очень не нравится. ⚙️ Почему так Индексы живут в B-Tree, а дереву нужен порядок. 🔹 BigInt с автоинкрементом → новая запись дописывается в конец. Мгновенно. 🔹UUIDv4 → случайный ID лезет в середину дерева. База рвёт заполненную страницу пополам и перетасовывает данные. Это и есть Page Split. 📉 Что происходит в продакшене Пока строк пара сотен тысяч — тишина. На миллионах начинается боль: 🔹тормозят INSERT — CPU занят не записью, а перебалансировкой фрагментация 🔹индекс пухнет в разы 🔹вымывание кэша — раздутый индекс не лезет в RAM, и база уходит на диск 🚀 Решение — UUIDv7 Отказываться от UUID не нужно. Просто бери седьмую версию. В начале строки — timestamp (время до миллисекунды), и только потом случайные биты. 🔹 Ключи всегда растут 🔹 Для базы это почти автоинкремент 🔹Записи ложатся в конец, фрагментация исчезает Скорость вставок остаётся ровной даже на таблицах в десятки гигабайт. 💡 Стартуешь проект? Закладывай UUIDv7 сразу.

👩‍💻 Поиск по ключевым словам всё чаще проигрывает реальным пользовательским запросам. Фразы-ключи требуют уже не совпадения слов, а понимания смысла. На открытом уроке: разберём, как построить современную систему семантического поиска для реального e-commerce проекта. Без абстрактной теории — только практическая работа с базой данных, SQL-запросами, генерацией эмбеддингов и интеграцией ИИ-инфраструктуры. покажем настройку PostgreSQL и pgvector, работу с Supabase, интеграцию фронтенда на React/Vite и бэкенда на Python,а также подключение ИИ-агента через MCP. После урока вы сможете проектировать базы данных с поддержкой векторного поиска, работать с текстовыми эмбеддингами и интегрировать современные ИИ-сценарии в реальные продукты. 🗓 Открытый урок пройдёт 4 июня в 20:00 МСК в преддверии старта курса «ИИ для разработчиков». Участие бесплатное. Подробности и регистрация: https://tglink.io/f047dad90f2545?erid=2W5zFGw93b7 Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

⚡Когда аналитика разнесена по отдельным системам, бизнес долго ждет данные и платит за лишние кластеры, ETL и серверы. 🐘Postgres Pro AXE — аналитическая СУБД от Postgres Professional на знакомом PostgreSQL. Ускоряет доставку аналитики и снижает TCO на хранение и обработку данных. ✔️До 20 раз быстрее Greenplum На сложных запросах в тестах ClickBench, TPC-H и TPC-DS. ✔️До 10 раз меньше ресурсов При сопоставимой нагрузке с MPP-аналогами. ✔️Аналитика ближе к рабочим данным Postgres Pro AXE работает как отдельная аналитическая СУБД или расширяет Postgres Pro Enterprise аналитическими возможностями на существующих узлах. ✔️Быстрый старт для команды Знакомый PostgreSQL снижает порог входа для администраторов и разработчиков. ✔️Свобода хранения и BI Локальный сервер, сетевая шара или S3. Данные — в формате Parquet. 🔗Приходите 28 мая на бесплатный вебинар: покажем, как построить аналитику без зоопарка технологий.

CHECK-ограничения в MySQL: валидация прямо в таблице ✅ Когда вы хотите убедиться, что в таблицу попадают только корректные данные — не всегда нужно писать сложную логику в приложении. Иногда достаточно встроенного механизма MySQL: ограничения CHECK. 🔹 Что такое CHECK? Это правило, которое автоматически проверяет значение в колонке при вставке (INSERT) или обновлении (UPDATE). Если правило нарушено — операция отменяется с ошибкой. Пример:

CREATE TABLE users (
  id INT PRIMARY KEY,
  age INT,
  CHECK (age >= 0 AND age <= 120)
);

Теперь нельзя вставить пользователя с возрастом -5 или 999 — MySQL просто не даст это сделать. Синтаксис CHECK 🔸 Можно добавлять при создании таблицы (CREATE TABLE) или позже (ALTER TABLE). 🔸 Можно использовать AND, OR, арифметику, сравнения, функции (с ограничениями). 🔸 Поддерживается в MySQL 8.0+. В старых версиях CHECK игнорировался (!). Пример с условием на строку:

CREATE TABLE products (
  id INT PRIMARY KEY,
  name VARCHAR(100),
  category ENUM('book', 'game', 'toy'),
  price DECIMAL(10,2),
  CHECK (price >= 0)
);

Здесь мы запрещаем отрицательные цены. Добавление ограничения в существующую таблицу:

ALTER TABLE users
ADD CONSTRAINT chk_age CHECK (age >= 0 AND age <= 120);

Что произойдёт при нарушении?

INSERT INTO users (id, age) VALUES (1, -10);
-- ERROR 3819 (HY000): Check constraint 'chk_age' is violated.

⚠️ Важно помнить: 🔹CHECK срабатывает только для новых данных — старые строки не проверяются. 🔹Если значение NULL, правило обычно не нарушается (NULL считается «неизвестным» и не сравнивается напрямую). 🔹Ошибку можно перехватывать в приложении, чтобы сообщить пользователю. ✅ Когда стоит использовать CHECK: 🔹 Для ограничений: возраст, положительная цена, длина строки, формат (через LIKE или REGEXP). 🔹Когда хотите, чтобы в таблице «по умолчанию» всегда были только корректные данные. 🔹Чтобы упростить валидацию и сделать БД самодостаточной (например, при работе с внешними источниками данных).

5 ФАТАЛЬНЫХ ОШИБОК В ГРАФИКАХ, КОТОРЫЕ ПОДРЫВАЮТ ДОВЕРИЕ К ВАШЕМУ АНАЛИЗУ Забирайте гайд с разбором основных ошибок в канале Сделай это красиво. Автор — Алексей Смагин, дата-журналист и аналитик Яндекса. ГАЙД ПОДОЙДЁТ: — аналитикам данных и продуктовым аналитикам — научным сотрудникам и исследователям — руководителям, которые работают с отчётностью — всем, кто делает презентации с графиками Умение анализировать — это круто. Но заказчики не видят вашу работу, они видят итоговые выводы. А от их оформления зависит, оценят ли результат. Научиться делать графики — это быстро и легко. Достаточно исключить базовые ошибки — и ваша инфографика сразу будет выглядеть профессиональнее. Подписывайтесь и забирайте гайд в закрепе: @perfectgraphs

Кажется, аналитика подошла к моменту больших изменений. Ещё недавно подготовка отчётов занимала дни: данные собирались вручную, цифры перепроверялись, а бизнес слишком долго ждал ответы. Сегодня искусственный интеллект меняет сам подход к работе с данными — делает аналитику быстрее, проще и доступнее. 3 июня Visiology проведёт большой онлайн-эфир Cortex LIVE о новом поколении аналитики. На бесплатном эфире покажут: — как ускорить получение аналитики — как сократить объём ручной работы — как быстрее находить ответы для бизнеса — как компании уже меняют подход к работе с данными Без сложной теории — только реальные примеры и практические сценарии. Если вы работаете с аналитикой, отчётностью или управлением, этот эфир точно стоит посмотреть. До мероприятия осталось совсем немного времени — успейте зарегистрироваться заранее, чтобы не пропустить эфир.

🆓 Ваши SQL-запросы работают, но через месяц их уже сложно прочитать и изменить? С ростом логики запросы превращаются в набор вложенных подзапросов. Разобраться в них сложно, поддержка занимает время, а любые изменения несут риск сломать результат. На открытом уроке разберём: как использовать обобщенные табличные выражения (CTE), чтобы писать сложные запросы по шагам. Покажем, как упростить структуру, сделать код читаемым и работать с иерархиями через рекурсивные CTE. 🗓 Урок проходит в преддверии старта курса «PostgreSQL для администраторов баз данных и разработчиков». Если вы хотите писать SQL, который легко читать и поддерживать — подключайтесь 27 мая в 20:00 МСК. 🔗 Регистрация открыта: https://tglink.io/79c7c811e717c6?erid=2W5zFJEXK6y Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Больше об CTE по ссылке https://sql-academy.org/ru/guide/operator-with

Ты аналитик. Ты тащишь на себе дашборды, A/B-тесты и SQL в 10 вкладках. А при мыслях об автоматизации задач и усилении своих скиллов, осекаешься - повышение квалифкации стоит десятки тысяч. Больше 60% работодателей уже заложили бюджет на развитие команды в этом году. Просто большинство аналитиков никогда не просят. Потому что не знают, как. Мы собрали полный гайд: → 8 шагов от «хочу прокачаться» до «компания всё оплатила» → Готовые обоснования для руководителя → Скрипты ответов на возражения → Чек-лист перед разговором с HR Здесь - твоя грамотная заявка на корпоративный грант. 📄 Забирай методичку бесплатно → https://tglink.io/7516d0cb076c3f Реклама. ООО "АЙТИ РЕЗЮМЕ". ИНН 4025460134. erid: 2W5zFHRhK4D

Задача из собеседования (VK, intern-аналитик): медиана зарплат по отделам без MEDIAN 📊 Любимый вопрос на собесах: проверяет понимание оконных функций и аккуратность с чётным/нечётным числом строк. 📋 Схема БД 🔹 employees (id, name, department, salary) 🎯 Формулировка Посчитать медианную зарплату для каждого отдела. Использовать MEDIAN / PERCENTILE_CONT нельзя — нужно реализовать руками. 📊 Пример данных

id name  dept salary
1  Анна  IT   80
2  Борис IT   120
3  Вера  IT   150
4  Глеб  HR   60
5  Дина  HR   90

Ожидаемый результат:

dept median
IT   120    ← центр из 3
HR   75     ← (60+90)/2

Разбор 🧠 Что такое медиана на пальцах 🔹 Сортируем зарплаты по возрастанию 🔹 Если строк нечётно — берём центральную 🔹 Если чётно — среднее двух центральных Для отдела с зарплатами [40, 50, 70, 100] медиана = (50 + 70) / 2 = 60. 1️⃣ Что нам нужно знать про каждую строку Чтобы найти «центральную» строку в отделе, нужны две вещи: 🔹 её позиция в отсортированном списке внутри отдела 🔹 общее число строк в отделе Обе задачи решают оконные функции — ROW_NUMBER() и COUNT(*) с PARTITION BY department. 2️⃣ Как найти центральные позиции Формула для центра: 🔹 FLOOR((cnt + 1) / 2) — нижняя центральная 🔹 CEIL((cnt + 1) / 2) — верхняя центральная Магия в том, что для нечётного cnt обе формулы дают одну и ту же строку — это и есть единственная центральная. Для чётного — две соседние, которые мы потом усредним. Проверим на наших данных: 🔹 IT (cnt=3): FLOOR(4/2)=2, CEIL(4/2)=2 → берём строку №2 → зарплата 120 ✅ 🔹 HR (cnt=2): FLOOR(3/2)=1, CEIL(3/2)=2 → строки №1 и №2 → (60+90)/2 = 75 ✅ 3️⃣ Решение через оконные функции

WITH ranked AS (
    SELECT 
        department,
        salary,
        ROW_NUMBER() OVER (
            PARTITION BY department 
            ORDER BY salary
        ) AS rn,
        COUNT(*) OVER (PARTITION BY department) AS cnt
    FROM employees
)
SELECT 
    department,
    AVG(salary * 1.0) AS median_salary
FROM ranked
WHERE rn IN (FLOOR((cnt + 1) / 2.0), CEIL((cnt + 1) / 2.0))
GROUP BY department;

CTE ranked внутри каждого отдела нумерует сотрудников от самой низкой зарплаты к самой высокой и параллельно считает общее число сотрудников. Внешний запрос оставляет только «центральные» строки и усредняет их. На что обратить внимание❗️ 🔹 Деление на 2.0, а не на 2 — иначе в некоторых БД получим целочисленное деление и логика для чётных отделов поедет 🔹 AVG(salary * 1.0) — та же история, если зарплаты хранятся в INT, без умножения на 1.0 результат округлится до целого 🔹 COUNT(*) посчитает и NULL-зарплаты как строки. Если такое возможно — используйте COUNT(salary) и заранее отфильтруйте WHERE salary IS NOT NULL, иначе ROW_NUMBER поставит NULL в начало и сломает порядок 🎁 Бонус: если PERCENTILE_CONT всё-таки доступен В PostgreSQL, Oracle, SQL Server задача решается в одну строку:

SELECT 
    department,
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY salary) AS median
FROM employees
GROUP BY department;

Но на собесе обычно просят именно «руками» — чтобы проверить, понимаете ли вы, что происходит под капотом 🔍 🎯 Что запомнить 🔹 Медиана руками = ROW_NUMBER + COUNT в одном CTE 🔹 Центральные позиции — FLOOR и CEIL от (cnt+1)/2 🔹 Делим на 2.0, а не на 2 — иначе целочисленное деление всё сломает 🔹 Если в БД есть PERCENTILE_CONT — используйте его; ручная реализация нужна только для собесов и старых MySQL (до 8.0 там вообще нет оконных функций — придётся через переменные)

❗️ SQL-запросы со временем превращаются в длинные конструкции: вычисления повторяются, логика расползается по коду, поддерживать запросы становится сложнее. 🚀 Функции SQL позволяют вынести вычисления и бизнес-логику в отдельный блок и использовать их повторно в разных запросах. 🗓 21 апреля в 20:00 МСК на открытом уроке разберём, чем функции отличаются от хранимых процедур, какие виды функций существуют и когда их применять. Покажем разницу между скалярными и табличными функциями, разберём создание функций на примере PostgreSQL и MS SQL Server, а также обсудим влияние функций на производительность запросов. Вы увидите практические примеры использования функций в бизнес-логике и научитесь структурировать SQL-код так, чтобы его было легче поддерживать. ➡️ Открытый урок проходит в преддверии старта курса «SQL для разработчиков и аналитиков». Зарегистрируйтесь и получите доступ к занятию: https://tglink.io/fd3eee7a304976?erid=2W5zFJmmRLM #реклама О рекламодателе

Один UPDATE — и данных больше нет. Как это починить? Представьте: прибегает продакт — «Почему у клиента цена 50к? Мы же вчера ставили 40к!» А в базе уже новое значение. Старое затёрто командой UPDATE. Восстановить нельзя. Никак. Если в проекте есть данные, которые меняются и за которыми нужно следить — цены, статусы, настройки — эта проблема рано или поздно прилетит. Это как редактировать документ без Ctrl+Z — каждое изменение уничтожает предыдущую версию. Для финансовой отчётности и аналитики — катастрофа. Разберём три способа этого избежать — от простого к мощному.

Как это работает — коротко:

1. Таблица-клон     
Rooms → триггер → Rooms_History
2. SYSTEM_TIME      
Rooms → база сама ведёт историю
3. JSONB-слепки     
Rooms → триггер → JSON-снимок в отдельную таблицу

1️⃣ Вариант 1: Таблица-клон Самый понятный способ. Рядом с основной таблицей (например, Rooms) создаём её копию — Rooms_History. Каждый раз, когда кто-то меняет строку в основной таблице, автоматический механизм (триггер) сначала сохраняет старую версию строки в копию, и только потом применяет изменение. Главная боль — Schema Drift. Допустим, разработчик добавил в основную таблицу новую колонку «площадь». Если он забыл добавить эту же колонку в таблицу-клон и обновить триггер — всё ломается. Подходит только там, где структура таблиц не менялась годами и не планирует. 2️⃣ Вариант 2: SYSTEM_TIME — встроенный видеорегистратор Некоторые современные базы данных умеют вести историю сами, без всяких таблиц-клонов и триггеров. Достаточно один раз включить функцию — и база начнёт запоминать, когда каждая строка появилась и когда изменилась. После этого можно буквально «заглянуть в прошлое» одной командой:

SELECT * FROM Rooms FOR SYSTEM_TIME AS OF '2026-01-01';

Эта строка говорит: «Покажи мне все комнаты в том виде, в каком они были 1 января 2026 года». Идеально для отладки: можно увидеть точное состояние данных в ту секунду, когда пользователь словил баг. Если нужна серьёзная аналитика и «путешествия во времени» — это лучший выбор. Но есть нюанс: SYSTEM_TIME поддерживают не все базы данных. В PostgreSQL и MariaDB это работает, а вот в MySQL — нет. 3️⃣ Вариант 3: История через JSONB-слепки Идея простая: каждый раз, когда строка меняется, мы берём её текущую версию, упаковываем целиком в один JSON-объект и сохраняем в отдельную таблицу. Если комнату не трогали полгода, ни одной новой записи за это время не появится. Допустим, у комнаты №42 три раза менялась цена. В таблице истории будет:

room  snapshot                           changed_at
42    {"price": 300, "status": "active"}  1 января
42    {"price": 400, "status": "active"}  15 марта
42    {"price": 500, "status": "paused"}  10 апреля

Хотим узнать цену в феврале? Берём последнюю запись до февраля — 300. Почему JSON, а не обычная таблица-клон? Потому что JSON — это «резиновый» контейнер. Неважно, сколько новых колонок добавили в основную таблицу — JSON примет их все без единого изменения в таблице истории. Та самая проблема Schema Drift из первого варианта здесь просто не существует. Ложка дёгтя: история раздувает базу Об этом забывают чаще всего. Если данные меняются часто, таблица истории за полгода легко вырастает до сотен гигабайт. Проверенная стратегия — разделять данные по «температуре»: 🔹«Горячая» история за последние 3 месяца — живёт в основной базе (PostgreSQL), к ней обращаются постоянно. 🔹 Всё, что старше — уезжает в «холодное» хранилище (ClickHouse, S3). Там место дешевле, а аналитика по миллионам старых строк работает даже быстрее. Итого, что выбрать: 🔹 Простая система, структура не меняется → Таблица-клон с триггером 🔹 Нужна точная аналитика и «путешествие во времени» → SYSTEM_TIME 🔹 Структура часто меняется, средний масштаб → JSONB-слепки И в любом случае — заранее решите, куда архивировать историю через год. Потом будет поздно.

Важная новость на российском ИТ-рынке: анонс национальной бесплатной СУБД для всех отраслей экономики💥 Для этого события Диасофт проведет первую в своей истории конференцию, посвященную промышленной эксплуатации СУБД и архитектуре корпоративных данных – День СУБД 2026. Два важных факта о Digital Q.DataBase от Диасофт: 🪄 Это СУБД – "полиглот", которая понимает диалекты Oracle, MS SQL и PostgreSQL, без переписывания кода приложений. 🪄 У решения первое место в рейтинге конвергентных СУБД по версии CNews 2025. Если вам интересна тема систем управления базами данных и нового подхода к их импортозамещению, приходите на наш День СУБД 2026! 💌 21 апреля в Кибердоме: 🟣 топ-менеджеры Диасофт расскажут о Национальной СУБД для обеспечения технологического суверенитета; 🟣 гости станут участниками деловой и музыкальной программы; 🟣 участники события смогут обменяться идеями и мнениями. Регистрируйтесь по ссылке и до встречи! #реклама О рекламодателе

Проект растет, и быстро искать нужные данные становится все сложнее? Ждем вас на авторском практикуме Дмитрия Кириллова «Разработка корпоративных RAG-систем на PostgreSQL» от ОТУС! О чём будет эфир: 💾Почему классический поиск и документация перестают работать в сложных системах 💾Что такое RAG-системы и как они устроены 💾Архитектура решения: от данных до ответа пользователю 💾Практика: реализация RAG на базе PostgreSQL 💾Как улучшать качество ответов и снижать галлюцинации Ведущий: Дмитрий Кириллов — педагог, соучредитель и технический директор одного из крупнейших сервисов онлайн-регистрации бизнеса в России. 🎁Бонусы для участников: 7% скидка на любой курс ОТУС + доступ к бесплатному пробному периоду корпоративной платформы 🎁Подарок - мини-курс по PostgreSQL Регистрация открыта: https://tglink.io/af4d251c1739d8 Увидимся на эфире! Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963. erid: 2W5zFJVxSLy