Коллега спросил: можно ли сделать JOIN двух таблиц, если у них нет ключей соединения?

Многие сразу отвечают: нет.
Но правильный ответ — да, можно.

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

Например, задача из аналитики.

Есть таблица clients:

- client_id
- name
- city

И таблица managers:

- manager_id
- name
- city

Нужно найти клиентов и менеджеров, которые живут в одном городе.

SELECT c.name AS client,
       m.name AS manager,
       c.city
FROM clients c
JOIN managers m ON c.city = m.city;

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

Важно помнить один момент:
если в городе 5 клиентов и 3 менеджера, результат будет 15 строк. SQL соединит каждого клиента с каждым менеджером. Поэтому при JOIN без ключей строки часто «умножаются».

Другой пример.

Есть таблица clients с датой выдачи карты и таблица orders с покупками. Нужно найти клиентов, которые совершали покупки в день получения карты.

SELECT c.client_id,
       o.order_id,
       o.order_date
FROM clients c
JOIN orders o
ON c.client_id = o.client_id AND o.order_date = c.card_issue_date;

Вывод простой:
JOIN — это не про ключи. JOIN — это про условие, которое логически связывает данные (хотя конечно JOIN по ключам будет наиболее эффективен).

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

Почему в PostgreSQL таблицы толстеют, даже если вы ничего не добавляете?

Представьте: вы делаете ремонт. Купили новый диван, старый решили выбросить. Но вместо того, чтобы вынести его на помойку, вы просто пододвигаете его к стенке и ставите новый рядом.

Комната та же. Места не прибавилось, места стало наоборот меньше. Дивана теперь два, только вот один из них вам уже не нужен и использовать вы его не будете.

Примерно так работает PostgreSQL, когда вы обновляете или удаляете данные.

Смотрите сами.

Допустим, есть пустая таблица: users

Вставляем туда одну строку:

INSERT INTO users VALUES (1, 'Иван', 'ivan@mail.ru');

В таблице одна строка. Всё хорошо.

Теперь Иван решил сменить почту. Выполняем UPDATE:

UPDATE users
SET email = 'ivan@yandex.ru'
WHERE id = 1;

С точки зрения человека — мы просто исправили поле.
С точки зрения PostgreSQL — мы создали новую версию строки, а старую пометили как «мёртвую». В PostgreSQL нет ластика, которым можно просто стереть часть строки и записать туда новую информацию. Это работает иначе.

Физически в таблице теперь лежат две строки. Одна живая, одна мёртвая. Живая строка с новой информацией про Ивана, а мертвая со старой.

То же самое с DELETE:

DELETE FROM users WHERE id = 1;

С точки зрения PostgreSQL — строка не исчезает. Она просто получает отметку «не в строю». Лежит там же, занимает место, но в выборку при написании SELECT не попадает.

Эти «мёртвые» строки и есть тот самый мусор.

Со временем, если таблица живёт активной жизнью — обновляется, удаляется, снова обновляется — мёртвых строк может становится все больше и больше.

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

К счастью для уборки в PostgreSQL есть свой «дворник» — процесс VACUUM. Он ходит по таблицам, находит мёртвые строки и вычищает их. Свободное место становится доступным для новых строк.

Но если мусора слишком много, а дворник не успевает — таблица продолжает пухнуть.

К чему это я?

Честно сказать это опасная ситуация, требующая вмешательства так как во первых производительность начнет деградировать, во вторых это может говорить о том, что некоторые процессы внутри системы не работают или работают не так как нужно. А возможно что то мешает этим процессам нормально функционировать.

Что делать, если кажется, что SQL — это не твоё

Знакомое чувство: сидишь над задачей, смотришь на запрос…
и в голове пустота.

Читаешь условие уже третий раз.
Пробуешь написать SELECT — не получается.
Потом вроде начинает получатся, но приходит он — JOIN и все опять посыпалось. А дальше еще подзапросы выглядывают из за угла...

И в какой-то момент появляется мысль:
«Наверное, это просто не моё».

У меня это чувство было, когда я впервые столкнулся с подзапросами и оконными функциями.

Я тогда открыл задачу, посмотрел на OVER (PARTITION BY ...)
и честно подумал:
«Ну всё… дальше базового SQL я не пройду».

Потому что обычные запросы вроде стали понятны:
SELECT, JOIN, GROUP BY.

А тут внезапно новые сложности:

ROW_NUMBER() OVER (PARTITION BY ...)

И кажется, что ты читаешь какой-то другой язык.

Я несколько раз пытался решить задачу.
Не получилось.

Потом закрыл ноутбук и подумал:
«Ладно. Вернусь завтра».

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

- что делает PARTITION BY
- чем это отличается от GROUP BY
- зачем нужен ORDER BY внутри окна

И постепенно картинка начала складываться.

Не сразу. Не за один вечер.

Но в какой-то момент ты вдруг ловишь себя на мысли:
«А ведь это на самом деле работает логично».

И вот что важно понять.

Когда вы учите SQL, вы не соревнуетесь с теми,
кто пишет запрос за 10 секунд.

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

Сегодня вы не понимаете JOIN.
Завтра начинаете понимать.
Через месяц спокойно используете оконные функции.

Это нормальный процесс.

Поэтому если иногда кажется, что SQL — это «не твоё»,
просто помни одну вещь:

Почти каждый, кто сейчас пишет сложные запросы, когда-то сидел над простым SELECT и тоже ничего не понимал.

Так что спокойно.

Ошибаться можно. Не понимать — можно.

Главное — не бросать.

Как я объяснял начальнику, почему нельзя просто взять и "починить базу"

Ситуация: утро понедельника, я только налил кофе, как влетает шеф:

— Слушай, тут проблема. Сайт тормозит. Клиенты жалуются. Сделай что-нибудь.

Я (спокойно): — Хорошо, сейчас посмотрю логи, проверю нагрузку, maybe индексы нужно подкрутить или запросы оптимизировать.

Шеф (нетерпеливо): — Слушай, не надо этих сложностей. Ты ж программист. Просто зайди в базу и почини.

Я: — ??

Шеф: — Ну там, кнопку нажми какую-нибудь. "Починить базу". Должна же быть такая кнопка?

Я пытаюсь объяснить, что база данных — это не холодильник, где есть волшебная кнопка "разморозка". Что нужно смотреть планы запросов, искать узкие места, maybe добавлять индексы, чистить мёртвые строки, проверять блокировки...

Шеф смотрит на меня как на инопланетянина:

— Слушай, ты меня грузишь. Вот у меня в машине — заглохла, открыл капот, постучал молотком, и поехала. А у тебя не так?

Я: — Ну, если я постучу молотком по серверу, он точно не поедет. Скорее, упадёт окончательно.

Шеф вздыхает: — Ладно, делай по-своему. Только быстро. И без этих ваших умных слов.

Я иду искать проблему. Нахожу: один кривой запрос от новой фичи делал полное сканирование огромной таблицы. Добавил индекс — всё полетело.

Прихожу к шефу: — Готово. Я там индекс навесил, теперь летает.

Шеф (с подозрением): — Индекс? Это типа оглавление в книжке?

Я: — Ну... да, типа того.

Шеф (довольно): — Вот видишь, а говорил сложно. Просто оглавление добавил. Я ж говорил — ничего сложного.

Я промолчал. Пусть думает, что я просто "кнопку нажал".

Оконные функции ранжирования в PostgreSQL

Когда нужно отсортировать строки и присвоить им место в рейтинге, в PostgreSQL используют оконные функции ранжирования.

Они работают через конструкцию OVER(), которая определяет окно строк, внутри которого происходит вычисление.

Чаще всего используется такой шаблон:

`FUNCTION() OVER (PARTITION BY ... ORDER BY ...)`

PARTITION BY — делит данные на группы
ORDER BY — задаёт порядок внутри группы

Теперь разберём основные функции ранжирования.

---------------------------------------------------------------------------------------------

ROW_NUMBER()

Присваивает уникальный номер каждой строке.

Даже если значения одинаковые — номера всё равно будут разными.

Пример:

`ROW_NUMBER() OVER (ORDER BY salary DESC)`

Где используется:

— нумерация строк
— выбор top N записей
— удаление дубликатов

Главная особенность:
никакие значения не считаются равными — у каждой строки свой номер.

---------------------------------------------------------------------------------------------

RANK()

Функция ранжирования с учётом одинаковых значений.

Если значения совпадают — строки получают одинаковый ранг, а следующий ранг пропускается.

Пример результата:

1
2
2
4

Пример использования:

`RANK() OVER (ORDER BY salary DESC)`

Часто используется для:

— рейтингов
— соревнований
— аналитики продаж

---------------------------------------------------------------------------------------------

DENSE_RANK()

Работает почти как RANK(), но без пропусков в рангах.

Пример результата:

1
2
2
3

Пример:

`DENSE_RANK() OVER (ORDER BY salary DESC)`

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

---------------------------------------------------------------------------------------------

NTILE()

Разбивает строки на N групп.

Пример:

`NTILE(4) OVER (ORDER BY salary)`

Данные будут разбиты на 4 группы примерно одинакового размера.

Где применяется:

— квартели
— перцентили
— сегментация пользователей
— распределение данных по группам

---------------------------------------------------------------------------------------------

💡 Коротко о разнице функций

ROW_NUMBER()
— просто нумерация строк

RANK()
— одинаковые значения получают одинаковый ранг, но есть пропуски

DENSE_RANK()
— одинаковые значения получают одинаковый ранг без пропусков

NTILE()
— делит строки на группы

---------------------------------------------------------------------------------------------

Оконные функции ранжирования — один из самых полезных инструментов SQL-аналитики.
С их помощью легко строить рейтинги, топы, сегментации и распределения прямо в запросе.

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: «Дисциплина в моделировании и валидации — это больше не "лучшая практика", это обязательное требование для выживания».