5 игр, чтобы подучить SQL (и не уснуть по дороге)

SQLPD — расследуете преступления как аналитик SQL-полиции. Каждое задание — отдельное дело.

SQL Island — выживаете после крушения на острове, выполняя SQL-задачи, чтобы выбраться.

SQL Murder Mystery — ищете убийцу в базе данных. Свобода действий и минимум подсказок.

Lost at SQL — спасаете подлодку и команду, проходя сюжетные SQL-челленджи.

SQL Squid Game — Решаете задачи по мотивам игры в кальмара, чтобы не повторить судьбу коллеги-аналитика.

#игры #sql

Как понять партиционирование: DWH для гуманитариев

На Tproger объяснили различные типы партиционирования — диапазонное, списковое и хешевое с примерами применения. Если вы подступились к действительно объемным базам, или просто столкнулись с постфиксом _* в BigQuery или других подобных продуктах, статья поможет разобраться.

#основы #sql

@zen_of_python

​​Ошибки, которые можно избежать в SQL: грабли начинающего аналитика

Если вы только начинаете работать с SQL, статья поможет избежать типичных ошибок (пропуски, доступы, производительность).

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

#основы #sql
@zen_of_python

Молчаливый «провал» INSERT

Вы запускаете SQL-запрос INSERT, и вроде всё просто. Нет ошибок. Но и данные не вставлены. Звучит странно? Такое действительно может случиться с PostgreSQL — и случается чаще, чем хотелось бы.


Как можно вставить данные и не вставить одновременно?

Когда INSERT не срабатывает, первое, что приходит в голову — ошибка. Но PostgreSQL умеет «глотать» такое — ведь вы сами его об этом попросили.

Виновник — ON CONFLICT DO NOTHING

INSERT INTO users (id, email) 
VALUES (42, '[email protected]')
ON CONFLICT (id) DO NOTHING;

Здесь мы явно говорим: "если произойдёт конфликт по id, ничего не делай". И PostgreSQL по умолчанию так и поступает.


Поведение UPSERT при множественных уникальных индекса

Представьте, что в таблице есть не один, а два уникальных индекса:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email TEXT UNIQUE,
    username TEXT UNIQUE
);

Теперь вы выполняете:

INSERT INTO users (email, username) 
VALUES ('[email protected]', 'johnny');

А если username = 'johnny' уже существует, но email ещё нет?

Вставка завершится ошибкой!

Так происходит, потому что ON CONFLICT (email) говорит PostgreSQL: «молчи, если конфликт по email, но бросай ошибку, если конфликт по чему-то ещё».

Чтобы избежать этого, используем:

ON CONFLICT DO NOTHING

Тогда PostgreSQL проигнорирует конфликт по любому индексу. Но это может спровоцировать проблемы, особенно при вставке пачкой


Как отладить такую ситуацию?

— Проверяйте rowcount после запроса. В Python/psycopg2, например:

cursor.execute(sql, values)
if cursor.rowcount == 0:
    print("Nothing inserted!")

— Добавьте RETURNING и логируйте:

INSERT INTO users (email, username)
VALUES ('[email protected]', 'johnny')
ON CONFLICT DO NOTHING
RETURNING id;

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

— Логируйте причину. Если вы используете логику вида DO UPDATE, можно добавить логи в `UPDATE`-часть или сохранять «причину отказа» отдельно.

#sql