354 миллиона рублей на Postgres в России: стоит ли учить эту СУБД прямо сейчас?

Ловите новость, которая напрямую отвечает на вопрос "Актуален ли PostgreSQL на российском рынке?".

Правительство Ленинградской области объявило масштабную закупку на импортозамещение баз данных. Цифры, от которых у разработчиков и администраторов БД загораются глаза:

Бюджет контракта: около 354 млн рублей

Объем: не менее 2300 лицензий СУБД Postgres Pro

Срок: внедрение до 2028 года в системах органов власти

Перед нами не просто очередная новость, а маркер того, куда движется рынок. Postgres Pro — это сертифицированная отечественная сборка на базе знакомого нам всем PostgreSQL. Государство выбирает этот стек как стандарт.

А теперь включаем режим турбо и думаем, что это значит для нас:

Рынку нужны люди. 2300 лицензий — это новые рабочих места. Кто-то должен эти базы ставить, настраивать, мигрировать на них данные с устаревших систем, а потом администрировать и разрабатывать под них запросы. Это не абстрактные вакансии, а вполне конкретные задачи с понятным горизонтом планирования до 2028 года.

PostgreSQL становится стандартом. Если государство (а за ним потянутся и госкорпорации, и крупный бизнес) массово переходит на PostgreSQL, значит, знание этой СУБД переходит из категории "плюшек" в категорию "must have". Для администраторов БД, разработчиков 1С, аналитиков данных — это базовый инструмент.

Импортозамещение = рабочие места. Проекты с бюджетами в сотни миллионов рублей не делаются "на коленке". Им нужны квалифицированные кадры. Специалисты, которые умеют работать с PostgreSQL на серьезном уровне (производительность, отказоустойчивость, миграция с Oracle/MSSQL), сейчас входят в золотую лигу.

Мой вывод:

Если вы выбираете, какую навык сейчас учить — PostgreSQL это очевидный выбор номер один. Это не просто "еще один инструмент в резюме", это прямой билет в крупные проекты с госфинансированием и реальные промышленные задачи.

Вчера на PG BootCamp Russia 2026 👨‍💻

Съездил, посмотрел, послушал. Пост-впечатление без воды.

Что круто:
— Доклады реально про пользу. Никакой воды, всё по делу: про производительность, про масштабирование, про подводные камни в продвинутых сценариях.
— Атмосфера камерная, но при этом много крутых спикеров. Можно было что то спросить, подискутировать. В этом формате это особенно ценно.
— Постгрес-сообщество живёт и активно развивается. Приятно видеть, сколько людей реально горят темой.

Коротко: не зря съездил. Вдохновение + новые идеи + знакомства.

Кстати, заметил, что сейчас всё больше разговоров про оптимизацию и про работу с данными в промышленных масштабах. Значит, направление выбрано правильно.

Ну и классика: сфоткался на фоне стенда 😎

Как я узнал, что PostgreSQL можно ускорить с помощью квантового компьютера (и это не шутка).

Сижу, листаю научные статьи (да, бывает и такое). И тут натыкаюсь на работу, где ребята реально подключили PostgreSQL к гибридному квантово-классическому солверу D-Wave.

Сначала подумал: очередная теория для конференций. А потом вчитался — и понял, что это реальный эксперимент с работающим прототипом.

Они взяли PostgreSQL 16.4, добавили pg_hint_plan (чтоб управлять порядком JOIN-ов), а вместо стандартного оптимизатора использовали гибридный квантово-классический подход: классическая часть собирает статистику (кардинальность, селективность), а квантовая решает комбинаторную задачу выбора оптимального порядка JOIN.

И знаете что?

На тестовых запросах (Join Order Benchmark) они получили:

Ускорение выполнения запросов до 92.7%

Один запрос, который выполнялся 3.5 секунды, стал отрабатывать за 0.27 секунды

Даже с учётом того, что запрос улетал в облако D-Wave (2.5–2.8 секунды туда-обратно), общее время сократилось в 1.4 раза

И главное — они сделали то, что никто до них вероятно не делал:

Поддержали bushy join trees (это когда можно джойнить не только линейно, а по-хитрому)

Не ограничились 5 таблицами, как в предыдущих попытках, а дошли до 17.

Встроили это в реальную базу, а не просто посчитали на симуляторе

Да, накладные расходы пока высокие — 2–3 секунды на вызов квантового солвера. Для простых запросов это не нужно. А вот для сложных аналитических, где обычный PostgreSQL иногда работает долго и выбирает неоптимальный план — разница может быть драматичной.

Авторы честно признают: не все 113 запросов ускорились. Но там, где ускорились — прирост колоссальный. А там, где не ускорились, деградация в среднем всего 11%. И 20% запросов получили bushy-планы, которые стандартный планировщик даже не рассматривал.

Честно, я сначала отнёсся скептически. Но когда увидел цифры и то, что они реально подняли это на PostgreSQL — стало интересно.

Квантовые вычисления в базах данных — это уже не "через 20 лет". Это уже сейчас, на реальных серверах, с реальным кодом, в гибридном формате, где квантовая часть помогает классическому оптимизатору там, где он справляется хуже.



P.S. Статья называется "Hybrid quantum–classical optimization for bushy join trees in PostgreSQL".

Привет, друзья!

Сегодня разберём одну тему, которая вроде бы “ну что там сложного”,
но на практике стабильно даёт ошибки даже тем, кто уже работает с SQL.

Речь снова про GROUP BY.
Но не в общем, а через конкретные косяки, которые встречаются постоянно.

❌ Ошибка №1. “Добавлю колонку в SELECT — база сама разберётся”

Пишешь такой запрос:

SELECT customer_id, order_date, SUM(amount)
FROM orders
GROUP BY customer_id;

И получаешь ошибку.

("Ну я же просто добавил поле, в чём проблема?")

А проблема в том, что после GROUP BY у тебя уже другой уровень данных:

👉 одна строка = один customer_id

А order_date — это уже деталь внутри группы.
И база такая: “Я не понимаю, какую дату тебе показать”

👉 первую? последнюю? случайную?

Поэтому правило:

либо агрегируй (MIN, MAX), либо не трогай

("База не угадывает твои мысли, ей нужно чёткое указание")

❌ Ошибка №2. Путаница WHERE и HAVING

Классика, которую вижу постоянно.

SELECT customer_id, SUM(amount)
FROM orders
WHERE SUM(amount) > 1000
GROUP BY customer_id;

Так не работает.

Почему?

👉 WHERE применяется до группировки
👉 А SUM(amount) появляется после

То есть ты фильтруешь то, чего ещё не существует.

Правильно:

SELECT customer_id, SUM(amount)
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 1000;

Запомни простую мысль:

👉 WHERE — фильтрует строки
👉 HAVING — фильтрует группы

❌ Ошибка №3. “Сгруппирую по имени клиента — и норм”

Очень коварная штука.

GROUP BY customer_name

Выглядит логично.
Но потом начинается магия:

два “Ивана Иванова” → одна строка
один и тот же клиент с разным написанием → две строки

👉 Итог: кривая аналитика

Правильный подход:

GROUP BY customer_id

А имя уже можно подтянуть отдельно.

("Группируем по идентификаторам, а не по тому, как это красиво выглядит")

Итог:

GROUP BY — это не просто “собрать строки вместе”.

И кстати 👇

В будущей версии PostgreSQL 19 появится интересная штука — GROUP BY ALL.

Смысл простой:

👉 база сама подставит в GROUP BY все неагрегированные поля из SELECT

То есть вместо:

SELECT customer_id, order_date, SUM(amount)
FROM orders
GROUP BY customer_id, order_date;

можно будет написать:

SELECT customer_id, order_date, SUM(amount)
FROM orders
GROUP BY ALL;

Удобно? Да.
Но расслабляться не стоит 🙂

("Если не понимаешь, что группируешь — никакой ALL не спасёт")

Зачем писать LIKE там, где нужно просто =?

Заметил: многие сравнивают строки через LIKE даже тогда, когда ищут точное совпадение.

Вот так:

SELECT *
FROM orders o
WHERE customer_id LIKE 'ALFKI';

Или еще хуже вот так:

SELECT *
FROM orders o
WHERE customer_id LIKE '%ALFKI%';

Хотя можно было вот так:

SELECT *
FROM orders o
WHERE customer_id = 'ALFKI';

Это работает. Но:

Индекс не используется (или используется неэффективно). На = индекс отработает идеально. На LIKE с константой и % — нет.

Читается тяжелее. Глаз цепляется за LIKE и думает: "Там точно какой-то поиск по шаблону". А на самом деле нет.

Привычка, которая выстрелит в спину. Однажды ты напишешь LIKE '%значение' — и запрос упадёт по производительности. А ты и не заметишь, потому что привык.

LIKE нужен для поиска по шаблону, который задает искомые символы или комбинации, а для констант нужно просто =.

Это как забивать гвозди микроскопом. Микроскоп классный, но молоток лучше.

Сколько строк в результате вернет этот SQL запрос ? Ответы пишите в комменты к посту)

«Сбер» выпустил GigaChat Ultra. 700 млрд параметров, суверенная архитектура и никаких импортных зависимостей

«Сбер» представил новую флагманскую модель ИИ — GigaChat Ultra.

Цифры, которые впечатляют:

- 700 млрд параметров
- Архитектура mixture of experts (когда внутри модели много маленьких «специалистов», а не один огромный)
- Двукратное ускорение генерации ответов по сравнению с предыдущей версией

Но главное не в цифрах. Главное — суверенность.

Модель полностью разработана и обучена внутри страны. Всё своё, никаких внешних зависимостей. Это уже не просто «отечественный аналог», а стратегический технологический фундамент на случай, если зарубежные модели вдруг станут недоступны.

На каких задачах модель показывает рост?

- Математика
- Право
- Финансы
- Медицина

И, что важно для нас, — отличные результаты в русскоязычном домене. Потому что английский модель учить не надо, она с нашим языком уже дружит.

Что умеет?

- Позиционируется как персональный ассистент:
- Использует поисковые и кодовые агенты (может сама искать информацию и писать код)
- Анализирует файлы
- Запоминает факты о пользователе (и даёт управлять этой памятью)

Что с внедрением?

Руководитель разработки сказал интересную вещь: главный тормоз сейчас — не технологии, а правовые ограничения и инерция восприятия общества.

Рынок генеративного ИИ меняется. Если раньше все смотрели только на OpenAI и Google, то теперь появляются сильные игроки с собственной инфраструктурой. И это круто — хотя бы потому, что конкуренция двигает прогресс.

Зачем аналитику SQL, если есть Excel? (Спойлер: чтобы выжить)

Давайте будем честными: Excel — это крутой инструмент. Он понятный, гибкий и в нем можно быстро набросать график для отчета. Но рано или поздно в карьере любого аналитика наступает момент, когда «экселька» начинает нещадно виснуть, а потом и вовсе вылетает с криком о нехватке памяти.

Почему же SQL — это не просто «еще один навык в резюме», а ваш главный инструмент выживания?

1. Объем данных: когда миллион — это предел
В Excel есть жесткий лимит — 1 048 576 строк на один лист. Для малого бизнеса этого может и хватит, но в серьезном проекте столько данных генерируется за пару часов. SQL смеется над этими цифрами: он легко «переваривает» миллиарды строк, пока вы спокойно пьете кофе.
(«Масштаб имеет значение, поверьте»).

2. Чистота и воспроизводимость
Вспомните этот ужас: вы получили чужую таблицу, где куча скрытых столбцов, странных формул и ячеек, покрашенных вручную. Понять логику расчета — настоящий квест. В SQL всё прозрачно: ваш код — это четкая инструкция. Его можно запустить снова, отдать коллеге на проверку или автоматизировать.

3. Мощность объединения (JOIN)
Связать пять таблиц в Excel через ВПР (VLOOKUP) — это верный способ повесить компьютер на полчаса. В SQL соединение таблиц по ключам — это базовая, мгновенная операция.
(«Связи должны работать на вас, а не против вашего процессора»).

4. Безопасность и первоисточник
В Excel данные легко случайно удалить или «поправить» не ту ячейку. В SQL вы работаете с копией данных или через запросы на чтение. Сами данные в базе остаются в сохранности, что критически важно для серьезной аналитики.

5. Автоматизация: работайте меньше, делайте больше
Настроить SQL-запрос, который каждое утро сам собирает свежие данные и отправляет их в дашборд — это стандарт. Делать то же самое вручную в Excel каждый понедельник — это путь к выгоранию.

Главная мысль: Excel идеален для финальной визуализации и быстрых правок «на коленке». Но SQL — это фундамент. Это двигатель, который позволяет вам доставать золото из гор сырой информации.

(«Не будьте заложниками ячеек, становитесь повелителями данных»).

Мы часто слышим, что за искусственным интеллектом будущее. Но прямо сейчас на примере Microsoft мы видим, какую цену за это будущее приходится платить. Акции компании обвалились на 24% с начала года — это худший результат со времен великого кризиса 2008 года.

Что пошло не так, когда на кону стоят миллиарды?

1. Аппетиты растут быстрее прибыли
Microsoft вливает в ИИ-инфраструктуру запредельные суммы. Только в 2026 году расходы составят $146 млрд, а к 2028-му могут доползти до $191 млрд. Это космические деньги. Проблема в том, что инвесторы не видят адекватной отдачи. Облачный сервис Azure замедляется, а Copilot пока не стал тем «золотым ключиком», который открывает кошельки всех пользователей.
(«Вливать деньги в бак — это хорошо, но только если машина едет быстрее»).

2. Иллюзия незаменимости
Пока Microsoft строит огромную и дорогую экосистему, на пятки наступают гибкие стартапы вроде OpenAI и Anthropic. Инвесторы всерьез опасаются, что клиенты предпочтут работать с создателями ИИ напрямую, минуя посредника в лице Microsoft. Это ставит под удар всю маржинальность бизнеса.

3. Ловушка ожиданий
Рынок перегрет ожиданиями «чуда». Но реальность такова: инфраструктура стоит дорого, аренда серверов растет, а реальное внедрение технологий в повседневную работу идет гораздо медленнее, чем рисуют в презентациях. Капитализация компании «похудела» на $360 млрд — это цена, которую рынок выставил за неоправданный оптимизм.
(«Будет больно, но реальность всегда берет свое»).

Главная мысль: Этот обвал — громкий звоночек для всего рынка. Нельзя бесконечно заливать деньги в технологию, если она не приносит понятной прибыли здесь и сейчас. Даже у самого крупного игрока в мире ресурсы не безграничны.

Транзакции в SQL: почему «ручной» DML — это всегда риск?

Друзья, сегодня поговорим о безопасности. Когда вы пишете INSERT, UPDATE или DELETE (те самые DML-операции), вы меняете живое тело базы данных. И если делать это «в лоб», без страховки, цена ошибки может быть фатальной.

Как оформляется транзакция?
В PostgreSQL всё просто. У вас есть три главных инструмента:

BEGIN — вы выставляете «оцепление». С этого момента всё, что вы делаете, происходит в изолированном пространстве.

COMMIT — вы подтверждаете изменения. Только после этой команды ваши правки увидят все остальные и они станут постоянными.

ROLLBACK — ваш «счастливый билет» назад. Если что-то пошло не так, эта команда мгновенно откатывает базу в состояние до слова BEGIN.

Почему при ручных операциях нужно ВСЕГДА открывать транзакцию явно?

По умолчанию многие клиенты (и сам Postgres) работают в режиме autocommit. Это значит: нажал Enter — данные изменились навсегда. И вот здесь кроются главные ловушки:

1. Тот самый «забытый WHERE»
Классика: ты хотел обновить статус заказа для одного клиента, но забыл дописать WHERE id = 5. Без явной транзакции ты только что обновил статус у всех миллиона клиентов.
(«В этот момент в офисе обычно становится очень тихо»).
Если бы ты сначала написал BEGIN, ты бы увидел в консоли: «UPDATE 1000000». Сказал бы: «Ой!», набрал ROLLBACK и пошел пить чай с целой базой.

2. Логическая целостность
Иногда одно действие в бизнесе — это три запроса в базе. Например, перевод денег: у одного отнять, другому прибавить, в лог записать. Если на втором запросе моргнет свет или пропадет связь, без транзакции деньги у одного уйдут, а другому не придут. Явная транзакция гарантирует: либо выполнится всё, либо ничего.

3. Проверка результата перед фиксацией
Когда ты открыл транзакцию руками, ты можешь сделать UPDATE, а следом — SELECT, чтобы убедиться, что всё изменилось именно так, как ты планировал. И только когда глаз радуется результату, давать команду COMMIT.

(«Возьмите за правило: заходите в базу подёргать данные — сразу пишите BEGIN. Это как пристегнуть ремень в машине: вроде и без него едет, но со стеной лучше не встречаться»).

Главная мысль: Явная транзакция превращает опасную операцию в контролируемый процесс. Это ваше право на ошибку, которое экономит нервы вам и деньги вашей компании.

Почему проектирование базы данных — это 70% успеха всего проекта?

Давайте признаем один факт: создать таблицы в базе можно за пять минут. Но спроектировать систему, которая будет работать годы, не превращаясь в клубок костылей — это отдельное искусство. Часто разработку начинают «от фронтенда» или «от бизнес-логики», оставляя базу на потом. И это большая ошибка.

Почему этапу проектирования нужно уделять максимум внимания еще до первой строчки кода?

1. База — это фундамент, который сложно передвинуть
Если вы ошиблись в цвете кнопки на сайте, это правится за минуту. Если вы ошиблись в логике связей между сущностями (например, не учли, что у одного договора может быть несколько соисполнителей), переделка затронет всё: от структуры таблиц до кода бэкенда и API.
(«Ошибки проектирования — самые дорогие в исправлении»).

2. Данные живут дольше, чем программный код
За время жизни проекта вы можете трижды переписать интерфейс и сменить три фреймворка на бэкенде. Но ваши данные — заказы, клиенты, транзакции — остаются с вами. Грамотная схема гарантирует, что эти данные сохранят свою целостность и через пять лет, какими бы инструментами вы их ни читали.

3. Производительность закладывается на старте
Многие думают: «Потом накинем индексов и всё полетит». Но индексы не спасут, если сама структура данных заставляет базу делать лишнюю работу. Правильное распределение данных по таблицам (нормализация) и выбор верных типов данных — это то, что позволяет системе «летать» на стандартном железе даже при росте нагрузки.

4. Бизнес-логика в зеркале базы
Проектирование базы — это лучший способ проверить, понимаете ли вы бизнес-процесс. Если вы не можете четко распределить данные по таблицам и настроить связи, значит, в самой логике продукта есть «белые пятна». Работа над схемой данных заставляет задавать правильные вопросы заказчику еще на берегу.
(«Хорошая схема БД — это фактически документация вашего бизнеса в табличном виде»).

Главная мысль: Внимание к деталям при разработке БД — это не перфекционизм. Это забота о будущем проекта. Когда схема логична и прозрачна, разработка идет быстрее, багов меньше, а новые фичи внедряются без боли.

«Почему у разработчиков случаются триггеры от слова "триггеры" (и когда они всё-таки нужны)» 🤯🐘

В мире баз данных триггеры — это своего рода «серые кардиналы». Они живут в тени, их не видно в коде приложения, но они обладают абсолютной властью над данными. И именно за это их ненавидят и обожают одновременно.

Почему триггеры превращают отладку в ад?

Основная претензия к триггерам — это скрытая логика. Представьте: вы пишете простейший UPDATE одной колонки. Вы ожидаете, что изменится одна цифра, но внезапно:

Обновляются еще пять таблиц.

Улетает письмо клиенту.

База выдает ошибку о нарушении бизнес-логики, которой вообще нет в вашем коде.

Вы идете в код приложения, перерываете весь Python/Java-бэкенд и... ничего не находите. Потому что логика спрятана «внутри» самой таблицы.

Главные «грехи» триггеров:

Невидимость. Новым разработчикам крайне сложно понять, почему система ведет себя именно так, если они не заглянули в DDL каждой таблицы.

Эффект домино. Один триггер вызывает другой, тот — третий. Получается каскад, который может уронить производительность всей базы или вызвать бесконечный цикл.

Сложность миграции. Перенести логику триггеров между разными СУБД — та еще задача, так как синтаксис процедурных языков везде свой.

Но если они такие плохие, зачем их оставили в 2026 году?

Несмотря на весь негатив, есть ситуации, где триггеры — это единственное элегантное решение.

Когда они реально нужны:

Железный аудит. Если вам нужно логировать каждое изменение в таблице (кто, когда и что поменял), триггер сделает это гарантированно. Даже если админ залез в базу руками в обход приложения — триггер всё запишет.

Поддержание сложных итогов (Aggregates). Например, у вас есть таблица заказов и таблица остатков на складе. Триггер может мгновенно вычитать товар при создании заказа. Это быстрее и надежнее, чем делать это на стороне приложения.

Принудительная целостность. Когда данные в таблицу могут лететь из десяти разных микросервисов, триггер — это последний рубеж обороны, который не даст записать кривые данные, какие бы ошибки ни допустили разработчики в коде.

(«Триггер — это как автоматическая ловушка в заброшенном замке: она сработает всегда, даже если вы про неё забыли. Главное — самому в неё не попасть при инвентаризации»).

Главная мысль: Триггеры — это инструмент «последнего шанса». Их не стоит использовать для обычной бизнес-логики, которую можно описать в коде. Но для задач безопасности и тотального контроля за целостностью данных ничего лучше еще не придумали.

Отчет State of Analytics Engineering 2026: Скорость в ущерб качеству? 📉🏗
Свежий аналитический отчет от dbt Labs вскрыл серьезный перекос в развитии современных систем данных. Индустрия разогналась до предела, но, похоже, забыла укрепить фундамент. Ускорение разработки с помощью ИИ происходит на фоне деградации механизмов контроля и доверия.

Основные выводы исследования, которые определяют повестку 2026 года:

1. Инфраструктура против человеческого ресурса
Расходы на облачные вычисления и хранилища (warehouse compute) растут у 57% компаний. При этом бюджеты на команды и специалистов увеличились лишь у 36%.
Возникает опасный разрыв: спрос на данные растет, инфраструктура раздувается, но количество людей, способных управлять этим хаосом, не увеличивается пропорционально. Вливание денег в «железо» не исправляет системные ошибки в архитектуре.

2. Дисбаланс в автоматизации
72% команд уже внедрили ИИ в написание кода. Однако автоматизация контроля качества, тестирования и мониторинга (observability) является приоритетом лишь для 24%.
Результат: код генерируется в разы быстрее, но механизмы его стабилизации не справляются. Скорость разработки опережает скорость контроля.

3. Кризис доверия и галлюцинации
71% респондентов выражают серьезную обеспокоенность тем, что недостоверные данные или «галлюцинации» ИИ доходят до конечных бизнес-заказчиков.
Проблема качества данных остается вызовом номер один. В условиях, когда пайплайны работают непрерывно и на высоких скоростях, цена одной ошибки возрастает многократно.

4. Отсутствие владельцев и дефицит грамотности
Фундаментальные проблемы никуда не исчезли:

41% организаций заявляют о неопределенности в вопросах владения данными (ambiguous ownership).

36% фиксируют низкий уровень грамотности в работе с данными (data literacy) среди стейджеров.

Главная мысль: 2026-й — это год контекста и дисциплины. Скорость больше не является преимуществом, если вашим данным нельзя доверять. Как сказала Пуджа Крахен из Okta: «Дисциплина в моделировании и валидации — это больше не "лучшая практика", это обязательное требование для выживания».

Сколько строк вернет этот SQL запрос ?

❗️Self-Join: Когда таблица ссылается сама на себя

Self-Join (самообъединение) — это обычный JOIN, в котором таблица соединяется с собственной копией. В SQL нет отдельной команды для этого, мы просто дважды указываем одну и ту же таблицу, но даем ей разные «имена» (алиасы), чтобы база не запуталась.

Зачем это нужно?
Самый живой пример — иерархия сотрудников.

В структуре компании у каждого сотрудника есть руководитель. Но руководитель — это тоже сотрудник, который числится в той же самой таблице. В итоге у нас есть колонка manager_id, которая ссылается на id из этой же таблицы.

Чтобы вывести в одном отчете имя сотрудника и имя его начальника, нам нужно «раздвоить» таблицу в запросе:

=============================
SELECT
e.name AS employee_name,
m.name AS manager_name
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.id;
=============================

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

Мы берем таблицу employees и называем её e (Employee — исполнитель).

Присоединяем её же под именем m (Manager — руководитель).

Условие ON e.manager_id = m.id связывает конкретного сотрудника с его шефом.

Почему это важно:
Если использовать INNER JOIN, то из отчета пропадет самый главный босс (генеральный директор), так как у него нет руководителя (manager_id будет NULL). Поэтому здесь мы используем LEFT JOIN, чтобы сохранить в списке всех, даже тех, над кем «только небо».

✅Итог:
Self-Join — это способ превратить плоский список сотрудников в понятное дерево связей. Если данные в одной строке зависят от данных в другой строке той же таблицы — вам нужен этот прием.

Почему age = NULL всегда возвращает «Ложь»?

Чтобы это запомнить, нужно понять философию NULL. В базах данных NULL — это не ноль и не пустая строка. Это неизвестность.

Представьте, что перед вами две закрытые коробки. Вы не знаете, что внутри первой, и не знаете, что внутри второй. Можете ли вы сказать, что их содержимое одинаково? Нет. Оно неизвестно.

В SQL любая операция сравнения с NULL (будь то =, >, < или !=) выдает результат UNKNOWN. А так как фильтр WHERE пропускает только те строки, где условие истинно (TRUE), строки с NULL просто отбрасываются.

Как запомнить это навсегда?
Используйте аналогию с «правилом детектива»:

Равенство (=) — это опознание: «Этот человек (данные) точно тот, кого мы ищем».

IS NULL — это констатация отсутствия: «У нас нет данных об этом человеке».

Вы не можете «приравнять» данные к их отсутствию. Вы можете только спросить: «Является ли это поле пустым?» (IS NULL) или «Содержит ли оно хоть что-то?» (IS NOT NULL).

Итог:
В SQL есть три типа логики: True, False и Unknown. NULL — это всегда неопределенность. Поэтому вместо знака равенства мы используем специальные операторы-проверки.

DISTINCT ON: Умный поиск уникальных строк
Обычный DISTINCT работает просто: он смотрит на всю строку целиком и убирает полные дубликаты. DISTINCT ON работает тоньше: он оставляет уникальные значения только по конкретным колонкам, которые вы укажете в скобках.

Зачем это нужно?
Представьте таблицу заказов. У вас есть customer_id (кто купил), order_date (когда) и amount (на сколько). Вам нужно получить список всех клиентов и для каждого вывести только его самый первый заказ.

Если использовать обычный DISTINCT, вы получите все уникальные комбинации дат и сумм. А с DISTINCT ON вы получите ровно по одной строке на клиента.

Как это пишется:

SELECT DISTINCT ON (customer_id)
       customer_id,
       order_date,
       amount
FROM orders
ORDER BY customer_id, order_date ASC;

Три правила работы с DISTINCT ON:

1. Порядок в ORDER BY: Это критически важно. Колонки, указанные в DISTINCT ON (...), должны быть первыми в списке ORDER BY. Это нужно базе, чтобы сгруппировать данные перед выбором строки.

2. Выбор «той самой» строки: Именно ORDER BY определяет, какая именно строка из группы дубликатов попадет в результат. Хотите последний заказ? Используйте DESC. Хотите самый дешевый? Сортируйте по amount ASC.

3. Читаемость: Этот оператор заменяет использование оконных функций (вроде ROW_NUMBER()), делая запрос короче и понятнее для тех, кто знает PostgreSQL.

Когда это использовать?
Когда нужно найти «самый первый/последний/лучший» объект в каждой группе.

Когда нужно быстро схлопнуть историю изменений до актуальных состояний (например, получить текущий статус для каждого пользователя из таблицы логов).

Главная мысль: DISTINCT ON — это способ сказать базе: «Сгруппируй данные по этим полям, отсортируй их внутри группы и отдай мне только верхнюю строку».

В чем магия ORDER BY 1?
В PostgreSQL разрешено указывать номер столбца из секции SELECT вместо его имени.

SELECT name, age, salary
FROM employees
ORDER BY 1; — Сортировка по полю name

Это экономит пару секунд времени и несколько нажатий клавиш. Но именно здесь заложена потенциальная проблема для вашего проекта.

Почему это ломается?

Основная проблема — жесткая привязка к структуре. Представьте, что через месяц вам понадобилось добавить техническое поле id в начало выборки.

Было:

SELECT name, salary FROM employees ORDER BY 1;
— Сортировка по имени (логично)

Стало:

SELECT id, name, salary FROM employees ORDER BY 1;
— Сортировка внезапно переключилась на ID

Если этот запрос зашит в коде приложения или в BI-отчете, визуализация «поплывет». Пользователь ожидал список по алфавиту, а получил набор данных, отсортированный по внутреннему идентификатору базы.

Почему это плохая практика (Code Review):

Скрытая логика. Читая ORDER BY 1, коллега (или вы через полгода) должен каждый раз возвращаться глазами к SELECT, чтобы понять, что именно сейчас является «первым». Имена столбцов (например, ORDER BY name) делают код самодокументированным.

Проблемы с рефакторингом. Любое изменение порядка полей в SELECT требует синхронного изменения всех ORDER BY и GROUP BY, завязанных на цифры. Шанс забыть об этом и выкатить баг — почти 100%.

Неявное поведение при SELECT *. Если использовать звездочку, то ORDER BY 1 будет сортировать по тому полю, которое идет первым в схеме таблицы. Если кто-то изменит схему (например, через ALTER TABLE), порядок строк в приложении изменится без предупреждения.

Когда это допустимо?

В консоли (psql, DBeaver), когда нужно быстро «повертеть» данные.

В очень длинных и сложных UNION, где имена колонок могут различаться, но типы данных совпадают.

Вердикт:

В черновиках — пожалуйста. В репозитории — только имена. Это признак профессионализма и заботы о тех, кто будет поддерживать ваш код.

(«Код пишется для людей, и только иногда — для машин. Не заставляйте людей считать колонки на пальцах»).

Массовые блокировки в Claude: как не потерять доступ к своим проектам
Американская нейросеть Claude от компании Anthropic начала масштабную волну блокировок аккаунтов. Под ограничения попали многие пользователи из России, включая разработчиков и ИТ-специалистов, для которых сервис стал важным рабочим инструментом.

Для справки:

Claude — это продвинутый чат-бот на базе ИИ, созданный выходцами из OpenAI. Его ценят за высокое качество работы с кодом и сложной аналитикой.

Антифрод-система — автоматический алгоритм безопасности. Он анализирует IP-адреса, платежные данные и использование VPN, чтобы выявлять подозрительную активность и блокировать доступ «рискованным» аккаунтам.

Почему это происходит?
Эксперты выделяют несколько ключевых факторов:

Ужесточение антифрод-политики. Постоянная смена IP-адресов через VPN и регистрация на зарубежные виртуальные номера выглядят для системы как мошенничество.

Соблюдение санкций. Компании обязаны следовать экспортным ограничениям США, что неизбежно ведет к отключению пользователей из неподдерживаемых регионов.

Защита данных. Anthropic борется с «дистилляцией» моделей — когда их нейросеть используют для обучения других алгоритмов, что запрещено правилами.

Чем это опасно?
Многие привыкли использовать Claude как полноценную рабочую среду, храня внутри историю исследований и проектную документацию. Блокировка происходит без объяснения причин, и доступ к этим данным восстановить практически невозможно.

Как минимизировать риски?
Регулярные бэкапы. Не оставляйте важные наработки только в чате. Копируйте ценные промпты и ответы в локальные хранилища.

Переход на API. Использование модели через API часто оказывается стабильнее, чем прямой доступ через интерфейс чата.

Разнообразие инструментов. Критически важные процессы опасно завязывать на одном зарубежном сервисе, который официально не работает в стране. Стоит присмотреться к мультимодельным средам или локальным решениям.

Эта ситуация — еще один сигнал о том, что ИИ-инструменты стали полноценной частью нашей инфраструктуры, и к управлению рисками в этой сфере нужно подходить максимально серьезно.

Подробный разбор ситуации и мнения экспертов читайте в материале РБК:www.rbc.ru/technology...

SQL как меню в ресторане: в чем сила декларативного подхода?

Большинство языков программирования — императивные. Когда вы пишете на них код, вы даете компьютеру пошаговую инструкцию: «создай переменную», «запусти цикл», «проверь условие», «прибавь единицу». Это похоже на приготовление блюда по рецепту, где вы сами стоите у плиты.

SQL работает иначе. Это декларативный язык.

Представьте, что вы пришли в ресторан. Чтобы пообедать, вам не нужно идти на кухню, чистить овощи и следить за температурой конфорки. Вы просто открываете меню и говорите: «Я хочу салат „Цезарь“ без сухариков». А кухня ресторана и повар уже сами решают как они будут готовить этот салат для вас.

Как это работает в базе данных:
Ваш запрос (Заказ): Вы формулируете только конечный результат.

«Мне нужны имена всех клиентов, которые совершили покупку в мае». Вы не объясняете базе, как именно перебирать строки или в какой оперативной памяти их хранить.

SELECT name FROM users WHERE last_purchase_date >= '2026-05-01';

СУБД (Кухня): Получив ваш запрос, система активирует «шеф-повара» — оптимизатор запросов. Он сам решает, как выполнить задачу быстрее:

- Использовать ли индекс (быстрый поиск по списку)?
- Просканировать ли всю таблицу целиком?
- В каком порядке объединять данные?

Результат (Блюдо): Вы получаете готовый набор данных. Вам не важно, какие внутренние алгоритмы использовала база, если результат соответствует вашему описанию в SELECT.

Фокус на задаче: Вы тратите время на описание того, что нужно получить, а не на написание сложных циклов и алгоритмов сортировки.

Оптимизация «под капотом»: Создатели баз данных (PostgreSQL, MySQL) постоянно совершенствуют алгоритмы поиска. Когда выходит обновление СУБД, ваш старый запрос может начать работать быстрее сам по себе, потому что «кухня» стала работать эффективнее.

Читаемость: Декларативный код гораздо ближе к человеческому языку. Понять суть запроса спустя месяц гораздо проще, чем разбираться в десяти вложенных циклах.

Итог: SQL позволяет нам быть «заказчиками», а не «исполнителями». Главное — максимально точно описать в запросе, какой «салат» вы хотите получить в итоге, чтобы система не принесла вам ничего лишнего.