现已上线！2025 年 Telegram 研究 — 年度关键洞察 
8 121
订阅者
-424 小时
-167 天
+130 天
帖子存档
PostgreSQL или MySQL?
Один из самых частых вопросов от разработчиков и DevOps - “Что лучше: PostgreSQL или MySQL?”. Давай без фанатизма, просто по фактам 👇
🔷 PostgreSQL:
🔵Поддержка JSONB с индексами - почти как NoSQL внутри SQL
🔵CTE, оконные функции, полнотекстовый поиск - топ для аналитики
🔵Расширяемость: можно писать свои типы, функции, операторы
🔵Хорош для сложных запросов, аналитики, геоданных (PostGIS)
🔻 Минусы:
– Сложнее в настройке и оптимизации
– Меньше хостингов out-of-the-box (но всё быстро меняется)
🔶 MySQL (особенно InnoDB / MariaDB):
🔵Быстрее на простых SELECT/INSERT, если запросы примитивные
🔵Больше ready-to-go хостингов и тулов для web
🔵Низкий порог входа - быстрее поднимается новичками
🔻 Минусы:
– Слабее в сложных SQL-конструкциях
– Нет нормальной поддержки CTE до недавнего времени
– JSON без индексации (в MySQL < 8.0)
Вывод:
🧠 Если делаешь CRM, веб-продукт или MVP с простыми запросами, MySQL зайдёт.
📊 Если строишь data-heavy приложения, BI, ETL или гео-системы, PostgreSQL без шансов.
📲 Мы в MAX
#db
👉 @database_info
Разбор кейса. Компания переехала с MongoDB на PostgreSQL - зачем и что пошло не так.
Стартап хранил всё в MongoDB — быстро, удобно, JSON-документы летят.
Но через год — бизнес растёт, появляются проблемы:
🔸 Запросы тормозят.
Mongo не любит сложные агрегаты с джойнами по коллекциям.
А бизнесу уже нужно:
– аналитика по заказам
– ретеншн-отчёты
– CRM-связи между сущностями
🔸 Дублирование данных.
Документы растут, становятся вложенными, обновлять — боль.
Классическая проблема: “Обновили e-mail юзера — забыли в двух местах”.
🔸 Сложность поддержки.
Без схемы трудно отследить, что где лежит. Новым разработчикам — боль.
🔁 Решение: PostgreSQL
– Явная схема → валидируем данные сразу
– Поддержка JSONB → можно переехать частями
– Сильный SQL → отчёты, джойны, агрегации — на ура
– Надёжность и mature-инструменты для миграций, бэкапов, мониторинга
⚠️ Подводные камни:
– Миграция данных: пришлось писать парсеры и валидаторы
– Пришлось переосмыслить структуру: из “гибкого” хаоса в нормализованную модель
– Команда училась писать SQL и настраивать индексы
✅ Зато теперь:
– Запросы летят
– Данные валидны
– Аналитика возможна
– Рост — без боли
Переход с NoSQL на SQL — это не “откат назад”, это осознанный апгрейд, когда бизнесу нужен контроль, скорость и предсказуемость.
📲 Мы в MAX
#db
👉 @database_info
💣 NULL — тихий саботаж в твоей БД
На первый взгляд,
NULL — просто отсутствие значения. Но на практике это частый источник багов, неверных аналитик и проблем в бизнес-логике.
📉 Антипаттерн: беспечное обращение с NULL
Примеры:
SELECT * FROM users WHERE age > 18; -- Пользователи с age = NULL не попадут
age = NULL тут "выпадает", ведь NULL > 18 → UNKNOWN.
WHERE col1 = col2 -- Не сработает, если хотя бы одно значение NULL
NULL не равно даже самому себе (NULL != NULL).
📉 Итоги: ошибки в JOIN'ах, WHERE-фильтрах, расчетах.
🛡 Как защититься:
✅ Явно учитывай NULL:
WHERE age > 18 OR age IS NULL -- если хочешь включить "неизвестный возраст"
COALESCE:
SELECT COALESCE(discount, 0) FROM orders -- подставим 0, если скидка не указана
NULL через IS NULL / IS NOT NULL
✅ Для агрегаций учитывай поведение NULL:
AVG(column) -- пропустит NULL'ы, но COUNT(column) тоже не посчитает их!
NULL — не "ничего", а "неизвестно".
Пиши запросы так, как будто NULL всегда где-то прячется — и он не на твоей стороне.
Сохрани, чтобы не ловить грабли 💥
📲 Мы в MAX
#db
👉 @database_info🚀 Подборка полезных IT каналов в Max
Системное администрирование, DevOps 📌
https://max.ru/i_odmin Все для системного администратора
https://max.ru/bash_srv Bash Советы
https://max.ru/sysadminof Книги для админов, полезные материалы
https://max.ru/i_odmin_book Библиотека Системного Администратора
https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др.
https://max.ru/tipsysdmin Типичный Сисадмин
Excel лайфхак 📌
https://t.me/Excel_lifehack Excel лайфхак
1C разработка 📌
https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С
Программирование C++📌
https://max.ru/cpp_lib Библиотека C/C++ разработчика
Программирование Go📌
https://max.ru/golang_lib Библиотека Go (Golang) разработчика
Программирование React📌
https://max.ru/react_lib React
Программирование Python 📌
https://max.ru/python_of Python академия.
https://max.ru/BookPython Библиотека Python разработчика
Java разработка 📌
https://max.ru/bookjava Библиотека Java разработчика
GitHub Сообщество 📌
https://max.ru/githublib Интересное из GitHub
Базы данных (Data Base) 📌
https://max.ru/database_info Все про базы данных
Фронтенд разработка 📌
https://max.ru/frontend_1 Подборки для frontend разработчиков
Библиотеки 📌
https://max.ru/programmist_of Книги по программированию
https://max.ru/proglb Библиотека программиста
https://max.ru/bfbook Книги для программистов
Программирование 📌
https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций
https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT
https://max.ru/php_lib Библиотека PHP программиста 👨🏼💻👩💻
Шутки программистов 📌
https://max.ru/itumor Шутки программистов
Защита, взлом, безопасность 📌
https://max.ru/thehaking Канал о кибербезопасности
https://max.ru/xakkep_1 Хакер Free
Книги, статьи для дизайнеров 📌
https://max.ru/odesigners Статьи, книги для дизайнеров
Математика 📌
https://max.ru/Pomatematike Канал по математике
https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике
Вакансии 📌
https://max.ru/progjob Вакансии в IT
Мир технологий 📌
https://max.ru/mir_teh Канал для любознательных
Бонус 📌
https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга
https://max.ru/mockva_life Свежие новости Москвы
https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП
Мини-гайд: Как ускорить SELECT’ы в PostgreSQL с помощью покрытия индекса (covering index)
Иногда индекс есть, а запрос всё равно тормозит. Почему?
👉 Потому что обычный индекс помогает найти строку, но потом БД всё равно лезет в таблицу, чтобы достать нужные поля. Это называется heap access — и это дорого.
📌 Решение — покрывающий индекс. Это индекс, который содержит все нужные поля прямо в себе. PostgreSQL с версии 11 умеет делать это через
INCLUDE.
🔧 Пример:
-- Запрос
SELECT name, email FROM users WHERE status = 'active';
-- Обычный индекс
CREATE INDEX idx_users_status ON users(status);
-- Покрывающий индекс
CREATE INDEX idx_users_status_cover ON users(status) INCLUDE (name, email);
Хотите стать аналитиком, но боитесь, что для вас вакантного места нет?
Это совершенно не так и вот почему: в 2026 году трудовую конкуренцию выигрывают не те, кто знает больше инструментов, а те, кто понимает, что именно нужно рынку прямо сейчас и готов подстраиваться под изменения бизнеса ⚙️
Заходите на бесплатный эфир, на котором не будет информации «как стать аналитиком за 30 дней», но будет подробный разбор карьеры аналитика и то как им стать в 2026 году.
Ведет Андрон Алексанян — CEO школы аналитики 📉📉📉📉📉📉, 8 лет в аналитике, работал с крупнейшими компаниями РФ и мира.
Что обещают разобрать:
🔶Как реально устроен вход в аналитику в 2026;
🔶Как думают нанимающие менеджеры — и что прямо бесит их в резюме;
🔶Какое портфолио сегодня реально смотрят;
🔶Почему кандидаты с меньшим опытом получают работу первыми — и как этим воспользоваться;
🔶Ну и про возраст 30 / 40 / 50+ тоже разберут — есть ли смысл стартовать сейчас.
Плюс всем зарегистрировавшимся дают урок по прохождению собеседований — обычно он только в платных курсах.
Эфир стартует уже совсем скоро!
📊 Зарегистрироваться бесплатно
🔗 Мини-гайд по JOIN-ам в SQL
JOIN — мощнейший инструмент в арсенале SQL. Но многие путаются в типах. Разбираем на пальцах:
🔸 INNER JOIN
Что делает: оставляет только совпадающие строки из обеих таблиц.
Когда использовать: когда нужны только те записи, у которых есть соответствие.
SELECT *
FROM orders o
INNER JOIN customers c ON o.customer_id = c.id;
NULL из правой, если нет совпадения.
Когда использовать: когда нужно сохранить всё из первой таблицы, даже если во второй нет данных.
SELECT *
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id;
NULL из левой, если нет совпадения.
Когда использовать: аналогично LEFT JOIN, но редко встречается, потому что просто меняем порядок таблиц.
🔸 FULL OUTER JOIN
Что делает: объединяет LEFT и RIGHT — берёт всё из обеих таблиц.
Когда использовать: когда важны все данные, даже без соответствий.
SELECT *
FROM table_a
FULL OUTER JOIN table_b ON table_a.id = table_b.id;
WHERE) после LEFT JOIN могут не дать ожидаемый результат.
Используй ON для условий соединения, WHERE — для фильтрации результата.
Сохрани, чтобы не забыть. А ты какой JOIN используешь чаще всего?
📲 Мы в MAX
#db
👉 @database_info
🧱 Антипаттерн: Ненормализованная схема в SQL
Когда нужно «быстро запилить фичу», руки тянутся сделать одну таблицу, где и заказ, и клиент, и товары — всё в куче.
Пример:
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_email TEXT,
product_1_name TEXT,
product_1_price NUMERIC,
product_2_name TEXT,
product_2_price NUMERIC
);
customers, orders, products, order_items.
2. Используй внешние ключи.
3. Не бойся JOIN'ов — они для этого и придуманы.
Пример нормализованной структуры:
-- Таблица клиентов
CREATE TABLE customers (
id SERIAL PRIMARY KEY,
name TEXT,
email TEXT
);
-- Таблица заказов
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(id)
);
-- Таблица товаров
CREATE TABLE products (
id SERIAL PRIMARY KEY,
name TEXT,
price NUMERIC
);
-- Связка товаров и заказов
CREATE TABLE order_items (
order_id INT REFERENCES orders(id),
product_id INT REFERENCES products(id),
quantity INT
);
⚡Когда аналитика разнесена по отдельным системам, бизнес долго ждет данные и платит за лишние кластеры, 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 мая на бесплатный вебинар: покажем, как построить аналитику без зоопарка технологий.
🎯 Мини-гайд: как НЕ спроектировать монстра вместо схемы БД
Когда проект только начинается, есть соблазн «не заморачиваться» и сделать одну большую таблицу на всё.
Спойлер: потом будет больно.
Вот как этого избежать 👇
1. Начинай с нормализации
– Смотри, какие поля повторяются.
– Разделяй по сущностям: клиент ≠ заказ ≠ товар.
– Нормальные формы — не академикам, а тебе на пользу.
2. Определи связи заранее
– Один ко многим? Многие ко многим?
– Используй
FOREIGN KEY, чтобы база помогала тебе, а не мешала.
3. Не бойся JOIN-ов
– Да, их становится больше.
– Но это лучше, чем сотни NULL - ов и "status_1", "status_2" в одной колонке.
4. Планируй под рост
– Временные костыли становятся постоянными.
– Заложи масштабируемость: разнос сущностей, отдельные таблицы для логов, истории, связей.
5. Назначь ID-шки как бог велел
– PRIMARY KEY + автоинкремент или UUID.
– Не делай email или name ключом — это путь в баги.
🧠 Помни: хорошо спроектированная схема ускоряет разработку, а не тормозит её.
А переделывать схему сложнее, чем сделать нормально с самого начала.
📲 Мы в MAX
#db
👉 @database_info
Антипаттерн: «Одна таблица на всё»
Когда бизнес-логика усложняется, а структура БД остаётся в духе Excel — жди беды.
🔴 Что это такое?
Проектировщик (часто на раннем этапе) создаёт одну большую таблицу, где:
– сотни колонок на все случаи жизни,
– куча
NULL-ов,
– смешаны данные разных сущностей (например, и клиенты, и заказы, и статусы).
Так проще… пока не начнётся работа с реальными данными.
💥 Что пойдёт не так:
– Производительность падает: индексы не работают эффективно.
– Сложность валидации и бизнес-логики.
– Трудно расширять: каждое изменение — как операция на открытом сердце.
– Нельзя нормально нормализовать: всё связано со всем.
✅ Как избежать:
– Используй нормализацию: выноси повторяющиеся и логически независимые данные в отдельные таблицы.
– Не бойся JOIN-ов — это не зло, а инструмент.
– Планируй схему БД под задачи, а не наоборот.
📌 Пример:
Плохо:
CREATE TABLE everything (
id INT,
client_name TEXT,
order_price DECIMAL,
order_status TEXT,
delivery_address TEXT,
...
);
CREATE TABLE clients (
id INT PRIMARY KEY,
name TEXT
);
CREATE TABLE orders (
id INT PRIMARY KEY,
client_id INT REFERENCES clients(id),
price DECIMAL,
status TEXT
);
🚀 Подборка полезных IT каналов в Max
Системное администрирование, DevOps 📌
https://max.ru/i_odmin Все для системного администратора
https://max.ru/bash_srv Bash Советы
https://max.ru/sysadminof Книги для админов, полезные материалы
https://max.ru/i_odmin_book Библиотека Системного Администратора
https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др.
https://max.ru/tipsysdmin Типичный Сисадмин
Excel лайфхак 📌
https://t.me/Excel_lifehack Excel лайфхак
1C разработка 📌
https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С
Программирование C++📌
https://max.ru/cpp_lib Библиотека C/C++ разработчика
Программирование Go📌
https://max.ru/golang_lib Библиотека Go (Golang) разработчика
Программирование React📌
https://max.ru/react_lib React
Программирование Python 📌
https://max.ru/python_of Python академия.
https://max.ru/BookPython Библиотека Python разработчика
Java разработка 📌
https://max.ru/bookjava Библиотека Java разработчика
GitHub Сообщество 📌
https://max.ru/githublib Интересное из GitHub
Базы данных (Data Base) 📌
https://max.ru/database_info Все про базы данных
Фронтенд разработка 📌
https://max.ru/frontend_1 Подборки для frontend разработчиков
Библиотеки 📌
https://max.ru/programmist_of Книги по программированию
https://max.ru/proglb Библиотека программиста
https://max.ru/bfbook Книги для программистов
Программирование 📌
https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций
https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT
https://max.ru/php_lib Библиотека PHP программиста 👨🏼💻👩💻
Шутки программистов 📌
https://max.ru/itumor Шутки программистов
Защита, взлом, безопасность 📌
https://max.ru/thehaking Канал о кибербезопасности
https://max.ru/xakkep_1 Хакер Free
Книги, статьи для дизайнеров 📌
https://max.ru/odesigners Статьи, книги для дизайнеров
Математика 📌
https://max.ru/Pomatematike Канал по математике
https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике
Вакансии 📌
https://max.ru/progjob Вакансии в IT
Мир технологий 📌
https://max.ru/mir_teh Канал для любознательных
Бонус 📌
https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга
https://max.ru/mockva_life Свежие новости Москвы
https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП
❌ Антипаттерн: Хранить даты и время в
VARCHAR
Встречали такое?
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
order_date VARCHAR(20)
);
'2024-12-01', '12/01/2024', '01.12.24', 'вчера' — всё ляжет, но работать с этим потом боль.
🔴 Сложность фильтрации и сортировки
Сравнение строк ≠ сравнение дат.
Запросы типа WHERE order_date > '2024-01-01' могут вести себя непредсказуемо.
🔴 Нельзя использовать функции времени
Ни DATE_TRUNC, ни AGE(), ни агрегаты по времени не работают нормально с VARCHAR.
✅ Как правильно
Используйте типы DATE, TIMESTAMP, TIMESTAMPTZ — они:
* валидируют данные на вставке;
* дают мощный инструментарий для анализа;
* упрощают работу с часовыми поясами и интервалами.
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
order_date TIMESTAMPTZ DEFAULT now()
);
🔎 Мини-гайд: Индексы в PostgreSQL — быстро и по делу
Индексы — главный инструмент для ускорения запросов. Но неправильное использование может только навредить.
Основные типы индексов в PostgreSQL:
-
B-tree — по умолчанию. Идеален для поиска по равенству и диапазону (=, <, >, BETWEEN).
- Hash — только для поиска по точному равенству (=). Становится актуальным реже.
- GIN — для массивов, JSONB, полнотекстового поиска.
- GiST — геоданные, поиск по диапазонам, сложные типы.
- BRIN — для очень больших таблиц с упорядоченными данными (например, логи).
Практические советы:
- Не злоупотребляй индексами: каждый индекс замедляет INSERT/UPDATE/DELETE.
- Следи за актуальностью: периодически проверяй и удаляй неиспользуемые (pg_stat_user_indexes поможет).
- Составные индексы ((col1, col2)) эффективны, только если условия WHERE учитывают порядок колонок.
- Используй EXPLAIN ANALYZE, чтобы понять, работает ли индекс в реальности.
Типичная ошибка:
Создать индекс на всё подряд без анализа запросов. Итог — тормоза на записи и огромный размер базы.
✅ Индексы — это как специи: мало — пресно, много — несъедобно.
Вывод:
Хотите быструю базу — планируйте индексацию так же внимательно, как сами запросы.
Сохрани, чтобы не забыть!
📲 Мы в MAX
#db
👉 @database_info
Сегодня я хочу рассказать вам про одну часто недооцененную фишку в PostgreSQL - partial indexes (частичные индексы).
Обычно мы создаём индексы на всю таблицу, но что если нам нужно ускорить только небольшую часть данных? Например, часто выбираются только активные пользователи (
status = 'active'). Вместо полного индекса можно создать индекс только для нужного поднабора данных:
CREATE INDEX idx_active_users
ON users (last_login)
WHERE status = 'active';
status = 'active'.
- Меньше нагрузка на диск при обновлениях таблицы.
🛠 Где это реально помогает:
- Таблицы с миллионами записей, где активно работают только с частью строк.
- Сценарии "горячих" и "холодных" данных.
Рекомендую попробовать partial indexes там, где обычные индексы слишком тяжелы или тормозят обновления!
📲 Мы в MAX
#db
👉 @database_infoКак перейти от простого обнаружения объектов к работающим сценариям мониторинга?
На основе координат из YOLO и данных трекера строим аналитику: пересечение виртуальных линий, контроль запретных зон, расчет времени нахождения в области. Математика перемещений превращается в конкретные бизнес-события.
Результаты урока:
Освоите работу с зонами интереса, научитесь подсчитывать события на видео и строить стабильные конвейеры «детектор + трекер + логика».
Спикер и руководитель курса по CV: Антон Витвицкий, руководитель команды компьютерного зрения в Boost Inc., опыт 14+ лет
Регистрируйтесь сейчас — напомним накануне: регистрация
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🚀 Сегодня я покажу вам один из моих любимых хаков для PostgreSQL – генерация серий дат без циклов и хранимок. Это идеальный способ быстро собрать таймлайн для аналитики или отчётов.
Сценарий: вам нужно построить список всех дат за последний месяц — например, чтобы потом сделать LEFT JOIN к таблице с событиями и увидеть, где были пропуски.
Вот как это делается с помощью
generate_series:
SELECT generate_series(
date_trunc('day', current_date) - interval '30 days',
date_trunc('day', current_date),
interval '1 day'
) AS day;
events, чтобы увидеть активность по дням:
SELECT
d.day,
COUNT(e.id) AS events_count
FROM
generate_series(
date_trunc('day', current_date) - interval '30 days',
date_trunc('day', current_date),
interval '1 day'
) AS d(day)
LEFT JOIN events e ON date_trunc('day', e.created_at) = d.day
GROUP BY d.day
ORDER BY d.day;
generate_series? А может быть, используете что-то подобное в других СУБД? Делитесь в комментариях👇
📲 Мы в MAX
#db
👉 @database_info🚨 Как понять, почему запрос тормозит?
Сегодня покажу простой, но действенный подход к диагностике медленных SQL-запросов. Когда к тебе приходит прод с жалобой "что-то всё виснет", важно не паниковать, а системно подойти к анализу.
Вот что я делаю первым делом:
1. Включаю
EXPLAIN (ANALYZE)
Это ваш лучший друг. Не EXPLAIN, а именно ANALYZE, чтобы получить реальные значения времени, а не план на бумаге.
2. Смотрю на узлы с наибольшим временем
Часто виновник — Seq Scan по большой таблице или Nested Loop с миллионами итераций.
3. Ищу несработавшие индексы
Был ли Index Scan или Index Only Scan? Если нет — стоит проверить, почему не сработал индекс. Может, фильтр не селективный?
4. Проверяю фильтрацию и сортировку
ORDER BY может убить всё. Особенно если не по индексу.
5. Думаю про статистику
ANALYZE делали недавно? PostgreSQL может строить плохой план, если у него устаревшие данные.
🛠 Если ты часто отлаживаешь SQL — советую поставить pgMustard или использовать EXPLAIN DEPOT. Они визуализируют планы и сразу показывают узкие места.
📲 Мы в MAX
#db
👉 @database_info
Антипаттерн: NULL в WHERE — и ты в ловушке
Когда в таблице есть
NULL, а в WHERE ты пишешь что-то вроде:
SELECT * FROM users WHERE age != 30;
age IS NULL — такие строки пропадут из выборки!
Почему? Потому что NULL != 30 не TRUE, это UNKNOWN.
А SQL возвращает строки только там, где WHERE → TRUE.
Как избежать?
1. Будь явно осторожен с NULL:
SELECT * FROM users
WHERE age != 30 OR age IS NULL;
NOT NULL.
– Если допускаешь NULL, продумывай поведение выборок.
3. Не верь глазам своим:
Даже count(*) и count(column) ведут себя по-разному из-за NULL.
Вывод:
NULL — это не ноль, не пустая строка и не "ничего".
Это "мы не знаем". И SQL ведёт себя с ним очень осторожно.
Сохрани, чтобы не словить грабли.
📲Мы в MAX
#db
👉 @database_info🆓 Ваши SQL-запросы работают, но через месяц их уже сложно прочитать и изменить?
С ростом логики запросы превращаются в набор вложенных подзапросов. Разобраться в них сложно, поддержка занимает время, а любые изменения несут риск сломать результат.
На открытом уроке разберём
как использовать обобщенные табличные выражения (CTE), чтобы писать сложные запросы по шагам.
Покажем, как упростить структуру, сделать код читаемым и работать с иерархиями через рекурсивные CTE.
🗓 Урок проходит в преддверии старта курса «PostgreSQL для администраторов баз данных и разработчиков». Если вы хотите писать SQL, который легко читать и поддерживать — подключайтесь 21 мая в 20:00 МСК.
🔗 Регистрация открыта: https://vk.cc/cXMPz2
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
