Дима SQL-ит 🧑‍💻 (Аналитика данных, AI)


Гео и язык канала: Россия, Русский
Категория: Технологии


👨‍💻 Блог аналитика данных в IT
📩 По менторству и сотрудничеству: @catdem

Связанные каналы

Гео и язык канала
Россия, Русский
Категория
Технологии
Статистика
Фильтр публикаций


Видео недоступно для предпросмотра
Смотреть в Telegram
P-value простыми словами:

Условие: подбросили монету 10 раз, выпало 9 орлов. Можно ли теперь говорить, что она подкручена?

1️⃣ Две версии Любая проверка начинается с двух гипотез:

H0 (нулевая) — эффекта нет. Монета честная, 50 на 50.
H1 (альтернативная) — эффект есть. Монету подкрутили.

В A/B-тесте ровно то же самое:
H0 — между вариантами разницы нет
H1 — разница есть. Нулевую гипотезу не доказывают, её пытаются опровергнуть.

2️⃣ Что вообще умеет честная монета:

Возьмём заведомо честную монету и бросим 10 раз. Получится какое-то число орлов. Повторим ещё и ещё — тысячу серий. Чаще всего выпадает 4, 5 или 6 орлов, реже 3 и 7. Это и есть распределение: не формула с неба, а результат повторения опыта.

3️⃣ Считаем точно:

Каждый бросок удваивает число раскладов:
1 бросок — 2 варианта,
2 броска — 4,
3 броска — 8.

Десять бросков дают 2¹⁰ = 1024 расклада, и у честной монеты все они выпадают одинаково часто. Сколько из них дают ровно 9 орлов? Столько, сколько мест у единственной решки:
Р О О О О О О О О О
О Р О О О О О О О О
О О Р О О О О О О О
... и так 10 штук — решка едет по всем местам

• 10 раскладов из 1024 — это 1%.
• Ровно 10 орлов — единственный расклад, 0.1%.
Шанс считается просто: сколько нужных раскладов делим на все 1024.

4️⃣ Откуда 2.15%

Нас интересует не «ровно 9», а «9 или ещё сильнее». Плюс зеркальный край: подкрутить монету могли и в сторону решки, 9 решек удивили бы нас так же.

Расклады:
9 орлов → 10 раскладов
10 орлов → 1 расклад
9 решек → 10 раскладов
10 решек → 1 расклад

Итого: 10 + 1 + 10 + 1 = 22 из 1024 = 2.15%
Вот эти 2.15% и называются p-value: как часто честная монета САМА, без всякой подкрутки, выдаёт такой же перекос или сильнее.

5️⃣ Порог Альфа:

Порог Альфа выбирают заранее, до теста. В бизнесе и A/B обычно 5%, в медицине 1% и строже.

2.15% < 5% → нулевую гипотезу отклоняем, монета скорее подкручена.

Сама альфа — это вероятность ошибки первого рода: эффекта нет, а мы его «нашли». С порогом 5% так будет выходить в 5 тестах из 100. Про ошибки первого и второго рода будет отдельный разбор.


Итог: 🤩

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓ Как объяснили бы p-value за 30 секунд на собеседовании? Пишите свою формулировку в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие разборы серии про A/B.


🚬 Вопросы, обучение, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit


📝 Как работают JOIN в SQL — разбор на пальцах:

Разберём, откуда берутся дубли и почему порядок таблиц в join важен.
Условие: Две таблицы, связаны по ключу users.id = orders.user_id:

users
id name
1 Аня
2 Боря
3 Вика

orders
user_id sum
1 500
1 300
2 700
4 900


У Ани два заказа, у Бори один, у Вики заказов нет. А заказ на 900 — от юзера 4, которого в users нет.

1️⃣ INNER JOIN — только совпадения
Берём каждую строку слева и ищем ей пару справа. Нет пары — строки нет.

SELECT u.name, o.sum
FROM users u
JOIN orders o ON u.id = o.user_id;

Аня 500
Аня 300
Боря 700


Вика вылетела — у неё нет заказов. Заказ на 900 вылетел — у него нет юзера.

2️⃣ Откуда дубли
Аня в результате дважды. Строку слева никто не копировал — просто справа ей нашлось два совпадения:
1 строка × 2 совпадения = 2 строки.

Отсюда классическая ошибка: COUNT(*) после JOIN считает не юзеров, а пары. Считать надо COUNT(DISTINCT u.id).

3️⃣ LEFT JOIN — все слева
Оставляем каждую строку левой таблицы. Нет пары — правая часть заполняется NULL.

SELECT u.name, o.sum
FROM users u
LEFT JOIN orders o ON u.id = o.user_id;

Аня 500
Аня 300
Боря 700
Вика NULL -- осталась, но пустая


4️⃣ Порядок таблиц решает
Тот же LEFT JOIN, то же ON. Меняем только одно — какая таблица стоит слева:

SELECT u.name, o.sum
FROM orders o
LEFT JOIN users u ON o.user_id = u.id;

Аня 500
Аня 300
Боря 700
NULL 900 -- заказ без юзера остался


Вики больше нет. Бережём мы теперь orders, а не users.
u LEFT o ≠ o LEFT u.

5️⃣ RIGHT JOIN — то же, но без перестановки
RIGHT держит все строки правой таблицы:

SELECT u.name, o.sum
FROM users u
RIGHT JOIN orders o ON u.id = o.user_id;


Результат тот же, что в шаге 4: o LEFT u = u RIGHT o. RIGHT почти не пишут — переставить таблицы и оставить LEFT читается проще.

6️⃣ FULL OUTER JOIN — не теряем никого
Всё с обеих сторон, чего нет — NULL:

Аня 500
Аня 300
Боря 700
Вика NULL -- юзер без заказов
NULL 900 -- заказ без юзера


FULL = LEFT + RIGHT. Удобно для сверки двух источников: сразу видно пропуски с обеих сторон.

7️⃣ CROSS JOIN — каждая с каждой
Единственный джойн без ON. 2 юзера × 2 промокода = 4 строки:

SELECT u.name, p.code
FROM users u
CROSS JOIN promo p;

Аня SALE10
Аня SALE20
Боря SALE10
Боря SALE20


Это декартово произведение: N × M строк. Нужен редко — например, разложить каждого юзера по всем дням календаря.

8️⃣ Цепочка из трёх таблиц
users → orders → payments, всюду LEFT:

SELECT u.name, o.id AS order_id, p.sum AS paid
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
LEFT JOIN payments p ON p.order_id = o.id;

Аня 10 500
Боря 20 NULL
Вика NULL NULL


3 строки — все юзеры на месте.

9️⃣ Ловушка: стартовали не с той таблицы
Джойны те же, LEFT. Меняем только стартовую таблицу:

FROM payments p
LEFT JOIN orders o ON o.id = p.order_id
LEFT JOIN users u ON u.id = o.user_id;

Аня 10 500


Одна строка.
Боря и Вика в набор даже не попали — платежа-то у них нет, а LEFT бережёт только то, что уже слева.
Стартовая таблица задаёт максимум строк: дальше их можно только размножить или отфильтровать, но не добавить новых.

🔟 Ловушка: INNER после LEFT
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
JOIN payments p ON p.order_id = o.id; -- обычный JOIN = INNER

Аня 10 500


LEFT честно донёс Борю с NULL и Вику с NULL.
А следующий INNER выкинул все строки без пары

Шпаргалка:
INNER — только совпадения
LEFT — все слева + совпадения
RIGHT — все справа + совпадения
FULL — всё с обеих сторон
CROSS — каждая с каждой (N × M)

Итог: 🤩  

❓  Все ли теперь стало понятно в теме join? Пишите в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit


🌐 Разбор задачи с собеседования в Яндекс. Парадокс Монти Холла:

Условие: Три двери, за одной приз, за двумя пусто. Вы выбрали дверь 1. Ведущий открыл дверь 3 — там пусто — и предлагает поменять выбор на дверь 2. Стоит ли изменить выбор?

1️⃣ Ловушка
Дверей осталось две, приз за одной. Кажется, шансы равны — 50 на 50.

Это самый частый ответ и он неверный. Ошибка в том, что мы считаем оставшиеся двери одинаковыми. А они не одинаковые: одну выбрали вы наугад, вторую оставил ведущий, который знает расклад.

2️⃣ Деталь, на которой держится вся задача
Ведущий знает, где приз. И у него связаны руки:

— вашу дверь он не трогает
— дверь с призом он не открывает

Значит его ход не случаен. Он не «просто открыл пустую дверь» — он был обязан открыть именно пустую. И этим он сливает вам информацию


3️⃣ Перебор: три расклада, больше их не бывает
Ваш выбор — дверь 1. Приз может быть за любой из трёх дверей, и все три случая равновероятны. Просто пройдём их по очереди и посмотрим, что даёт СМЕНА выбора.

• Приз за дверью 1 (вы угадали сразу)
Ведущий открывает 2 или 3 — обе пустые. Меняете → попадаете на пустую. ✗ мимо

• Приз за дверью 2
Ваша дверь 1 пустая, дверь 3 пустая. Открыть 1 он не может (ваша), открыть 2 не может (там приз) — остаётся дверь 3. Меняете → берёте дверь 2 с призом. ✓ приз

• Приз за дверью 3
Зеркально: он обязан открыть 2. Меняете → берёте дверь 3 с призом. ✓ приз

Итого смена выигрывает в 2 случаях из 3.

4️⃣ Почему так получается
Посмотрите, когда смена проигрывает. Ровно в одном случае — если вы угадали приз с первого раза. А это 1 шанс из 3.

Дальше просто:

вы угадали сразу → 1/3 → смена проигрывает
вы не угадали → 2/3 → смена ВСЕГДА выигрывает

Во втором случае смена выигрывает не «иногда», а всегда: если ваша дверь пустая, то из двух оставшихся одна с призом, и пустую ведущий уже открыл за вас. Он своими руками сложил все ваши 2/3 в одну-единственную дверь.

Остаться: 1/3 (33%)
Поменять: 2/3 (67%)

Ваш первый выбор как был 1/3, так им и остался — ведущий про вашу дверь ничего не сообщил, он и не мог её открыть. Зато про две другие сообщил всё.

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Какой ответ вы дали первым — 50 на 50 или сразу «менять»? И смогли бы объяснить почему? Пишите в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit

813 0 12 30 28

🛒 Разбор задачи с собеседования в Авито:

Условие: в мешке три кубика — на 6, 12 и 20 граней. Взяли один наугад, бросили — выпало 12. Бросаем этот же кубик ещё раз. Какова вероятность, что выпадет число меньше 12?

1️⃣ Что понятно сразу
6-гранный отпадает: числа 12 на нём просто нет. Значит в руке либо 12-гранный, либо 20-гранный.

2️⃣ Почему не 50 на 50
12 выпадает на этих кубиках по-разному: на 12-гранном — 1 раз из 12, на 20-гранном — 1 раз из 20. Раз у вас она выпала, вероятнее, что в руке именно 12-гранный.

3️⃣ Насколько именно чаще
Чтобы сравнить кубики честно, дадим каждому одинаковое число бросков. Возьмём 60 — оно делится и на 12, и на 20, поэтому получатся целые числа:

12-гранный: двенадцатка выпадет 60 : 12 = 5 раз
20-гранный: двенадцатка выпадет 60 : 20 = 3 раза

Итого 12-ть выпало 8 раз: пять раз с 12-гранного и три — с 20-гранного.

А если взять не 60 бросков, а другое число?
Ничего не изменится — важна только пропорция, а не сама цифра:

по 120 бросков → 10 и 6
по 600 бросков → 50 и 30
по 60 бросков → 5 и 3

Везде одно и то же: 12-гранный даёт 12-ать в 5 случаях из 8. Число 60 удобно только тем, что делится нацело: возьми 50 — вышло бы 4.17 и 2.5, та же пропорция.

При чём тут эти 8 случаев
По условию 12-ать уже выпало. Значит все броски, где выпало что-то другое, к вам не относятся — вы находитесь внутри тех самых 8 случаев. И в пяти из них у вас в руках 12-гранный кубик. Вот и всё, никакого 50 на 50.


4️⃣ Второй бросок
Считаем, как часто на каждом кубике выпадает меньше 12. Подходят числа от 1 до 11 — это 11 нужных граней:

на 12-гранном: 11 граней из 12 = 92%
на 20-гранном: 11 граней из 20 = 55%

Осталось соединить это с восемью случаями. В пяти из них у вас в руках 12-гранный и шанс 92%, в трёх — 20-гранный и шанс 55%. Считаем среднее по всем восьми, как среднюю оценку в классе:

(5 × 92% + 3 × 55%) / 8 ≈ 78%



5️⃣ Второй случай из тестового: выпало 4
Логика ровно та же, только теперь подходят все три кубика. Снова по 60 бросков каждым:

6-гранный: 60 : 6 = 10 четвёрок
12-гранный: 60 : 12 = 5
20-гранный: 60 : 20 = 3
всего 18 случаев

Меньше 4 — это 1, 2 и 3, то есть 3 нужные грани:
на 6-гранном: 3 из 6 = 50%
на 12-гранном: 3 из 12 = 25%
на 20-гранном: 3 из 20 = 15%

Среднее по восемнадцати случаям:
(10 × 50% + 5 × 25% + 3 × 15%) / 18 ≈ 37%


Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Встречали эту задачку на собеседованиях? Пишите в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit


🏦  Разбор задачи с собеседования в Т-Банке (Тинькофф). Тест точен на 99%, он положительный — но вы, скорее всего, здоровы:

Ранее мы разобрали, как работает условная вероятность и формула Байеса.
Если пропустили, то вот сам пост.

Давайте разберем на эту тему популярную задачу, которую спрашиваю во многих компаниях.

Условие: болезнь встречается у 1% людей. Тест находит болезнь у больного в 99% случаев, а у здорового ошибочно кричит «+» в 5% случаев. Вам пришёл положительный результат. Какова вероятность, что вы действительно больны?

Почти все на автомате отвечают «99%». Правильный ответ — 16.7%. Разберём, почему.

1️⃣ Вопрос не тот, на который вы ответили:
В условии дано P(+ | болен) = 99% — «тест сработает, если человек болен».
А спрашивают P(болен | +) — «человек болен, если тест сработал».

Это разные вопросы, и цифры у них разные. Формула Байеса как раз переворачивает условную вероятность с одной стороны на другую.


2️⃣ Считаем по головам — 10 000 человек:
Забудем про проценты и посчитаем живых людей:
• больных: 1% от 10 000 = 100 человек
• здоровых: 9 900 человек

Прогоняем всех через тест:
• из 100 больных тест поймает 99% = 99 человек
• из 9 900 здоровых тест ошибочно испугает 5% = 495 человек

тест + тест − всего
болен 99 1 100
здоров 495 9405 9900
всего 594 9406 10000

Смотрим столбец «тест +»: плюс получили 594 человека, а больны из них только 99.

P(болен | +) = 99 / 594 = 1/6 ≈ 16.7%


3️⃣ Тот же ответ формулой Байеса:
Сначала выпишем всё, что даёт условие — новых чисел дальше не появится:

P(болен) = 0.01 — болезнь у 1% людей
P(здоров) = 0.99 — остальные 99%
P(+ | болен) = 0.99 — тест ловит больного
P(+ | здоров) = 0.05 — ошибка на здоровом

⚠️ Два разных числа выглядят одинаково: 0.99 — это и точность теста, и доля здоровых. Не перепутайте, кто где стоит.

Числитель — только больные с плюсом:
P(болен) × P(+|болен) = 0.01 × 0.99 = 0.0099 → это наши 99 человек

Знаменатель — почему он именно такой
Мы ищем долю: из всех, у кого плюс, сколько по-настоящему больны. Значит внизу должны стоять ВСЕ плюсы, а не только больные — иначе это будет не доля.

А плюс может прийти ровно из двух мест:
• тест поймал больного → 0.01 × 0.99 = 0.0099 → 99 человек
• тест ошибся на здоровом → 0.99 × 0.05 = 0.0495 → 495 человек

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

P(+) = 0.0099 + 0.0495 = 0.0594 → 594 человека

Внутри каждой группы мы умножаем по одному правилу: «какая группа по размеру» × «какая доля в ней даёт плюс». Для здоровых это 0.99 × 0.05 — 99% людей здоровы, и 5% из них тест пугает зря.

Делим: 0.0099 / 0.0594 ≈ 0.167 = 16.7%

Ровно те же 99 и 594, что мы посчитали по головам. Формула ничего не выдумывает — она просто записывает подсчёт людей на языке вероятностей.



Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Встречали эту задачку на собеседованиях? Пишите в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit


💰 ARPU vs ARPPU — разберемся в чем разница:

ARPU и ARPPU постоянно путают. Обе про доход с пользователя, но делят на разное. Разберём и выведем главную формулу.

1️⃣ ARPU — доход на ВСЕХ
Всю выручку делим на всех активных, даже на тех, кто ничего не заплатил.
ARPU = выручка / все юзеры
SELECT
SUM(revenue) / COUNT(DISTINCT user_id) AS arpu
FROM payments;

2️⃣ ARPPU — доход на ПЛАТЯЩИХ
Та же выручка, но делим только на тех, у кого платёж больше нуля.
ARPPU = выручка / платящие
SELECT
SUM(revenue) / COUNT(DISTINCT CASE WHEN revenue > 0 THEN user_id END) AS arppu
FROM payments;

3️⃣ Связь — доля платящих
доля платящих = платящие / все юзеры = CR to pay (часто 1–5%)
Отсюда главное тождество:
ARPU = ARPPU × доля платящих
И всегда ARPPU >= ARPU.

4️⃣ Куда расти
Тождество показывает два рычага роста:
• поднять долю платящих — онбординг, триггеры оплаты
• поднять ARPPU — апселл, тарифы, допродажи

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Что еще разобрать? Пишите в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit


🎲 Формула Байеса и условная вероятность — разбор на кубике:

Условие: кинули кубик и говорят — выпало чётное. Какова вероятность, что это шестёрка?

Ответ: не 1/6, а 1/3. Покажу через формулу Байеса и расшифрую в ней каждое слагаемое — это и есть самое главное.

1️⃣ Обозначим события:
A — «выпала шестёрка» (это мы ищем)
B — «выпало чётное» (это уже известно — условие)
Нужна вероятность A, если известно B.

2️⃣ Сама формула Байеса:
P(A|B) = P(B|A) × P(A) / P(B)
Читается: вероятность A при условии, что произошло B.

3️⃣ Разбираем каждый кусок формулы:
• P(A|B) — что ищем: шанс шестёрки, раз выпало чётное. Это и есть ответ.
• P(A) — базовый шанс шестёрки, без подсказок = 1/6.
• P(B) — шанс чётного вообще: чётные это 2, 4, 6, то есть 3 из 6 = 1/2.
• P(B|A) — шанс, что чётное, ЕСЛИ выпала шестёрка = 1. Шестёрка всегда чётная.

4️⃣ Подставляем числа:
P(A|B) = P(B|A) × P(A) / P(B) = 1 × (1/6) / (1/2) = (1/6) / (1/2) = 1/3

5️⃣ Почему получилось именно так:
Подсказка «чётное» выкинула варианты 1, 3, 5. Осталось 2, 4, 6 — и шестёрка одна из трёх. Формула дала ровно это: 1/3. Информация подняла шанс шестёрки с 1/6 до 1/3 — в этом вся суть Байеса.

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  А вы сразу сказали 1/3 или попались на 1/6? Делитесь в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие разборы.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit


📊 DAU, WAU, MAU и sticky factor — метрики активности:

Пришло время разбираться с метриками, начнем с DAU, WAU, MAU и sticky factor 😘

1️⃣ Что это
DAU — уникальные пользователи за день
WAU — за 7 дней
MAU — за 30 дней
Ключевое слово — уникальные: один user_id считаем один раз, сколько бы раз он ни заходил.

2️⃣ Считаем все три одним запросом
SELECT
COUNT(DISTINCT CASE WHEN dt = CURRENT_DATE THEN user_id END) AS dau,
COUNT(DISTINCT CASE WHEN dt >= CURRENT_DATE - 6 THEN user_id END) AS wau,
COUNT(DISTINCT CASE WHEN dt >= CURRENT_DATE - 29 THEN user_id END) AS mau
FROM events;

COUNT(DISTINCT …) убирает повторы, CASE WHEN задаёт окно по дате.

3️⃣ Частая ошибка
WAU — это не сумма семи DAU. Кто заходил все 7 дней, в сумме DAU посчитан 7 раз, а в WAU — один.
Отсюда правило: DAU ≤ WAU ≤ MAU.

4️⃣ Sticky factor
sticky factor = DAU / MAU — показывает, как часто пользователи возвращаются.
0.1 → заходят ~3 дня в месяц (слабо)
0.2 → ~6 дней
0.5 → ~15 дней (уровень соцсетей)
Чем выше — тем «липче» продукт.

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Как вам такие разборы в формате видео? Делись в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit

1k 0 14 10 43

🛒  Разбор задачи с собеседования Магнит OMNI (MAGNIT TECH).
Сколько покупок нужно, чтобы собрать все 10 стикеров?


Условие: В наборе 10 наклеек. На кассе дают одну случайную за любую покупку. сколько покупок нужно, чтобы собрать все 10?

Задача на пониманием и умение считать математическое ожидание. Разберём на пальцах:

1️⃣ Главное правило: переворачиваем дробь
Если вероятность равна p, то среднее количество попыток до первого успеха равно 1/p. Например:
Вероятность 1/10 → 10/1 = 10 попыток
Вероятность 5/10 → 10/5 = 2 попыток

2️⃣
Шанс поймать новую наклейку
Собираем по этапам. Чем больше наклеек в альбоме, тем реже попадается новая:
этап 1: собрано 0 → шанс новой 10/10
этап 2: собрано 1 → шанс новой 9/10
...
этап 10: собрано 9 → шанс новой 1/10

3️⃣
Собираем матожидание и считаем ответ
Переворачиваем шанс каждого этапа в число покупок и складываем всё:
этап 1 (запишем общую формулу):
E = 10/10 + 10/9 + 10/8 + ... + 10/2 + 10/1

этап 2 (вынесем общий множитель за скобки):
E = 10 × (1 + 1/2 + 1/3 + ... + 1/10

этап 3 (считаем ответ):
E = 10 × 2.93 ≈ 29 покупок
Почти половина из этих них уходит на последние 2-3 наклейки.

Итог:
 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Сколько у вас получилось до того, как дочитали до ответа? Делись в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit

1.2k 0 21 10 32

Собесы, собесы, собесы…

Если тебе интересны обзоры собеседований и разборы заданий, то можешь заглянуть на канал Айти-Пингвин | Дата инженер. Это канал дата-инженера, который активно делает обзоры пройденных собесов, разбирает задачки и технологии, а также рассказывает о своем карьерном пути.

Что, на мой взгляд, будет полезно для собесов на аналитика?

1. На джуна разбор вопросов по SQL , вопросы про джоины и задача на джоины.

2. На мидла - задачи по SQL + оптимизация SQL-запросов. Будет очень полезно и джунам.

3. Порадовали задачи на адекватность. 😅 Будь готов, что на собесе спросят что-то совсем базовое и простое, но некоторых такие задачи вгоняют в ступор :) С разрешения Пингвина приведу загадки с собеседования.

Вот еще несколько интересных постов:
• Статья по индексам и партициям
• Транзакции и ACID
• Итоги за год
• Удаление дублей в Greenplum
• История о потере данных

Из последнего:
обзоры собесов в сбер (1, 2, GigaData)
• Neoflex
• Обзор большого собеседования с IT_One
• Лига цифровой экономики (проект Альфа банк)
• Популярные вопросы с hr скрининга
• Очередные вопросы по SQL с собеседования


В целом, на канале разнообразный контент. Заходите и изучайте😁

it пингвин | data engineer 🐧


🏦 Разбор задачи с собеседования в Тинькофф (Т-банк). Задача про светофор сколько минут ты теряешь на красном?

Условие: Каждый день едете на работу. На пути один светофор: 2 минуты горит зелёный, 1 минуту — красный. Сколько времени вы ожидаемо простоите за 100 поездок?

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

1️⃣ Находим цикл светофора
Полный цикл = 2 + 1 = 3 минуты. Вы приезжаете к светофору в случайный момент — считаем, что равномерно распределённый по этим 3 минутам.

2️⃣ Считаем вероятности
P(зелёный) = 2/3 → ждать 0 минут
P(красный) = 1/3 → придётся постоять

3️⃣ Сколько ждать, если попали на красный?
Вот тут сыплются многие. Вы ждёте не всю минуту. Вы приезжаете в случайный момент красной фазы: иногда в самом начале (придется ждать 1 минуту), иногда в конце (придется ждать 0 минут). В среднем — получим:
Среднее ожидание на красном = (1+0)/2 = 0.5 минуты

4️⃣ Собираем матожидание за одну поездку
E = P(зелёный) × 0 + P(красный) × 0.5
E = (2/3) × 0 + (1/3) × 0.5
E = 1/6 минуты ≈ 10 секунд

5️⃣ Умножаем на 100 поездок
100 × 1/6 ≈ 16.7 минуты = 16 минут 40 секунд

Итог: 🤩  

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓  Сколько у вас получилось до того, как дочитали до ответа? Делись в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации:  Написать в ЛС | mentor.dima-sqlit.ru 


@dima_sqlit


Видео недоступно для предпросмотра
Смотреть в Telegram
🗂 Порядок выполнения sql запроса — и почему алиас в WHERE не работает:

Часто вижу одну и ту же ошибку — человек пишет запрос, придумывает алиас в SELECT, а потом пытается использовать его в WHERE или HAVING. И получает ошибку. Почему?

Всё дело в порядке выполнения SQL.
На самом деле SQL выполняется совсем не в том порядке, в котором мы его пишем. Вот реальная последовательность:

1️⃣ FROM — сначала движок идёт к таблицам
2️⃣ JOIN
 — потом движок соединяет таблицы
2️⃣ WHERE — фильтрует строки до группировки
3️⃣ GROUP BY — группирует данные
4️⃣ HAVING — фильтрует уже сгруппированные данные
5️⃣ SELECT — только сейчас вычисляются выражения и алиасы
6️⃣ ORDER BY — сортировка результата
7️⃣ LIMIT — обрезание до нужного числа строк

Пример 1 — классическая ошибка с алиасом:
-- ❌ Не работает — алиас revenue ещё не существует на шаге WHERE
SELECT
order_id,
amount * 0.9 AS revenue
FROM orders
WHERE revenue > 1000;

-- ✅ Правильно — повторяем выражение напрямую
SELECT
order_id,
amount * 0.9 AS revenue
FROM orders
WHERE amount * 0.9 > 1000;

Пример 2 — почему HAVING, а не WHERE:
-- ❌ Нельзя — WHERE выполняется ДО GROUP BY
SELECT
user_id,
COUNT(*) AS order_count
FROM orders
GROUP BY user_id
WHERE order_count > 5;

-- ✅ Правильно — HAVING фильтрует после группировки
SELECT
user_id,
COUNT(*) AS order_count
FROM orders
GROUP BY user_id
HAVING COUNT(*) > 5;

Пример 3 — вот почему все пишут CTE:
Иногда хочется сначала что-то посчитать, а потом фильтровать по результату. Именно для этого и придумали CTE — они позволяют «сохранить» промежуточный результат и работать с ним как с таблицей.
-- ✅ CTE решает проблему: сначала считаем, потом фильтруем
WITH revenue_calc AS (
SELECT
order_id,
amount * 0.9 AS revenue
FROM orders
)
SELECT *
FROM revenue_calc
WHERE revenue > 1000;

Видите? В CTE SELECT уже выполнился — алиас revenue существует — и теперь во внешнем запросе WHERE отрабатывает по нему без проблем.

Итог: 🤩

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓ Сталкивались с этой ошибкой? Или, может, объясняете это джунам — как объясняете? Пишите в комментах!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit

1.3k 0 22 12 24

🤖 Что такое MCP сервер — как научить нейросеть писать SQL под ваши данные (часть 2):

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

Проблема: модель не знает ваши таблицы 🎚

Фиксированный тул — например get_sales_by_region — работает хорошо для простых запросов. Но что если пользователь спросит: «Сравни выручку по регионам с прошлым кварталом с разбивкой по сегментам клиентов»?

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

Решение: дать модели два инструмента — получить схему и возможность выполнить любой запрос.

Как это устроено: 🎚

@mcp.tool()
def get_database_schema(domain: str = "all") -> str:
"""
Возвращает схему БД: таблицы, поля, типы данных и связи.
Вызывай ПЕРЕД тем как писать SQL-запрос.
domain: 'sales', 'customers', 'products' или 'all'
"""
if domain == "all":
files = ["sales.md", "customers.md", "products.md"]
else:
files = [f"{domain}.md"]

result = ""
for f in files:
with open(f"docs/{f}", "r") as file:
result += file.read() + "\n\n"
return result

@mcp.tool()
def execute_sql(query: str) -> list:
"""
Выполняет SELECT-запрос к базе данных.
Используй только после get_database_schema.
Только SELECT — никаких изменений данных.
"""
conn = sqlite3.connect("metrics.db")
cursor = conn.cursor()
cursor.execute(query)
result = cursor.fetchall()
conn.close()
return result

Модель сначала вызывает get_database_schema, читает описание таблиц и связей — потом сама пишет SQL и передает в execute_sql.

Как организовать файлы схемы: 🎚

Файлы лежат рядом с сервером в папке /docs. Внутри — описание таблиц, типы данных и как они связаны:
## Таблица orders
- order_id INT — первичный ключ
- customer_id INT — FK → customers.customer_id
- region VARCHAR — регион продажи
- revenue FLOAT — выручка
- created_at DATE — дата заказа

## Связи
orders.customer_id → customers.customer_id

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

Один MCP или несколько? 🎚

Один MCP-сервер = один проект. Не нужно плодить отдельный сервер под каждую таблицу. Все связанные таблицы и тулы живут в одном сервере. Если у вас две независимые системы — например аналитическая база и CRM — вот тогда имеет смысл делать два разных сервера. Здесь нет явного ответа, нужно подходить индивидуально к каждому проекту.

А если схема хранится в Confluence? 🎚

Рабочий вариант — тул делает запрос к Confluence API и достает описание нужной таблицы прямо оттуда:
@mcp.tool()
def get_table_docs(table_name: str) -> str:
"""
Достает описание таблицы из корпоративной документации.
Используй перед написанием SQL если нужны детали схемы.
"""
# запрос к Confluence API
response = requests.get(
f"{CONFLUENCE_URL}/rest/api/content",
params={"title": table_name, "expand": "body.storage"},
auth=(USER, TOKEN)
)
return response.json()["results"][0]["body"]["storage"]["value"]


🟢 Хотите еще про нейронки ?
🔥 Набираем 80 реакций на этот пост, чтобы подобные посты выходили чаще

Итог: 🤩

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓ Какие идеи для использования MCP есть у вас? Делись в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit


🏠 IT ипотека (Часть 2) — как я проектировал квартиру (Remplanner, Pinterest, ChatGPT):

Когда берёшь черновую квартиру — впереди не просто ремонт, а целый проект. Надо придумать планировку, расстановку мебели и понять, как это вообще будет выглядеть в натуре. Делюсь своим стеком инструментов которые я использовал.

🎚 Инструмент 1 Remplanner:

Это был мой основной инструмент на этапе планировки квартиры.
Работает прямо в браузере по сути autocad, но с большим количеством готовых инструментов и шаблонов.

Что я делал в Remplanner:
• Прорабатывал разные варианты планировки
• Расставлял мебель и проверял, насколько удобно всё помещается
• Планировал розетки, выключатели и освещение
• Смотрел, как будут выглядеть комнаты в 3D
• Формировал понятные чертежи для строителей

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

В итоге ещё до начала ремонта понимаешь, как будет выглядеть квартира и избегаешь части дорогих переделок.

🎚 Инструмент 2 — Pinterest:

Это этап «насмотренности».
Работает так:
• Вбиваете запрос: например, «квартира 45 кв», «скандинавский стиль серый» — и просто смотришь
• Постепенно понимаешь, что тебе нравится, а что нет
• Сохраняешь понравившееся → вырисовывается общее направление

Повторить всё один в один с Pinterest не получится — дорого или нереализуемо. Но это и не нужно. Важно сформировать своё видение.

🎚 Инструмент 3 — ChatGPT:

Когда стены уже возведены — делаешь фотографию реального пространства и загружаешь в ChatGPT. Дальше:
• «Хочу здесь поставить диван, что посоветуешь?»
• «Как можно оформить этот угол?»
• «Что сюда органично впишется по цвету?»

ChatGPT накидывает варианты прямо под ваш конкретный интерьер (приложил пример, как я подбирал кухню).

🔥 Набираем 70 реакций на этот пост, чтобы посты про IT ипотеку выходили быстрее

Итог: 🤩


❓ Чем пользовались при ремонте или перестановке? Делитесь в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие посты.

🚬 Вопросы, менторство, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit

929 0 15 40 55

🤖 Что такое MCP — как дать нейросети доступ к вашим данным (часть 1):

Если вы уже работаете в Cursor, Claude Code, Codex, LM Studio или другой IDE где есть нейросети — вы наверняка встречали термин MCP. Разберем, что это и зачем нужно.

Что такое MCP? 🎚

MCP (Model Context Protocol) — открытый стандарт, который позволяет ИИ-клиенту подключаться к внешним данным и системам через специальные инструменты — Tools.

Без MCP модель работает только с тем, что ты вставил ей в чат.
Хочешь узнать метрику из своей базы — скопировал данные вручную, вставил, получил ответ.
MCP убирает этот шаг: модель сама идет в твою базу, достает нужное и отвечает.
Вы просто спрашиваете.

Схема простая:
• MCP Клиент — ваша среда (Cursor, Claude Desktop, Codex, LM Studio и другие)
• MCP Сервер — ваш код с инструментами
• Tool — функция, которую модель вызывает сама, когда понимает что она нужна

Скиллы — это же то же самое? 🎚

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

Может показаться, что скилл умеет то же самое, что и mcp и возникает вопрос — зачем нужен mcp?

Можно ведь написать скилл, который запускает bash или Python.
Но вот в чём различия — это не скилл запускает скрипты.
Cursor и другие IDE сами имеют встроенные инструменты: запуск команд, чтение файлов, редактирование кода — они зашиты внутрь приложения, никак не связаны с MCP.

• Скилл — это промпт, который говорит модели «используй вот этот встроенный инструмент вот так».
• MCP — другая история. Вы пишете свой код и подключаете его через протокол. Теперь у модели есть инструмент, который делает ровно то, что вы закодили — без ограничений клиента.

Пишем свой MCP-сервер на Python: 🎚

Библиотека fastmcp делает это просто:
from mcp.server.fastmcp import FastMCP
import sqlite3

mcp = FastMCP("WorkMetrics")

@mcp.tool()
def get_sales_by_region(region: str) -> list:
"""
Возвращает продажи по указанному региону за текущий месяц.
Используй когда пользователь спрашивает о продажах или
выручке по региону.
"""
conn = sqlite3.connect("metrics.db")
cursor = conn.cursor()
cursor.execute(
"SELECT date, revenue FROM sales WHERE region=?", (region,)
)
result = cursor.fetchall()
conn.close()
return result

if __name__ == "__main__":
mcp.run()

Прописываем сервер в mcp.json — и всё.
Пишете в чате: «Покажи продажи по Москве» — модель сама вызывает нужный инструмент.


🟢 Хотите еще про нейронки ?
🔥 Набираем 80 реакций на этот пост, чтобы подобные посты выходили чаще

Итог: 🤩

На посты про MCP меня вдохновило вот это видео — рекомендую к просмотру для большего понимания.

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓ Уже пробовал MCP если да, то какие? Делись в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit

1k 0 21 26 49

📊 SQL трюк — как добавить строку «Все категории» к любому отчёту через ROLLUP (ЧАСТЬ 2):

В прошлом посте мы добавляли итоговую строку через UNION ALL — это рабочий метод, но есть способ элегантнее.

Знакомьтесь:
GROUP BY ROLLUP — встроенный механизм SQL для автоматических итогов.

🟢 Что такое ROLLUP на пальцах:

ROLLUP — это расширение GROUP BY, которое автоматически добавляет строки с агрегатными итогами. Вместо того чтобы писать второй запрос и клеить через UNION ALL — просто добавляем одно слово

🟢 Шаг 1 — пишем запрос с ROLLUP:

SELECT
category,
SUM(revenue) AS total_revenue,
COUNT(order_id) AS orders_count
FROM orders
GROUP BY ROLLUP(category)

Результат:
category | total_revenue | orders_count
Одежда | 7000 | 2
Обувь | 1200 | 1
Техника | 2500 | 1
NULL | 10700 | 4

Итоговая строка появилась автоматически, но в поле category стоит NULL — это сигнал ROLLUP, что строка является итогом по всей группе.

🟢 Шаг 2 — заменяем NULL на «Все категории»:

Используем COALESCE, чтобы подменить NULL на читаемую метку:
SELECT
COALESCE(category, 'Все категории') AS category,
SUM(revenue) AS total_revenue,
COUNT(order_id) AS orders_count
FROM orders
GROUP BY ROLLUP(category)

Результат:
category | total_revenue | orders_count
Одежда | 7000 | 2
Обувь | 1200 | 1
Техника | 2500 | 1
Все категории | 10700 | 4

Чисто и лаконично — никакого второго запроса.

🟢 Важный момент — а что если в данных уже есть NULL в category?

Представим, что в таблице есть строки с незаполненной категорией:
order_id | category | revenue
1 | Одежда | 1500
2 | Обувь | 1200
3 | NULL | 800 ← категория не указана
4 | Одежда | 5500

Запускаем запрос с COALESCE — и получаем проблему:
category | total_revenue | orders_count
Одежда | 7000 | 2
Обувь | 1200 | 1
Все категории | 800 | 1 ← это был NULL из данных!
Все категории | 10700 | 4 ← это реальный итог ROLLUP

COALESCE не различает: это NULL из данных или NULL от ROLLUP — он заменяет оба.

🟢 Решение — используем GROUPING():

Функция GROUPING(column) возвращает 1, если строка итоговая (от ROLLUP), и 0 — если это обычная строка с NULL из данных:
SELECT
CASE
WHEN GROUPING(category) = 1 THEN 'Все категории'
ELSE COALESCE(category, 'Не указана')
END AS category,
SUM(revenue) AS total_revenue,
COUNT(order_id) AS orders_count
FROM orders
GROUP BY ROLLUP(category)
ORDER BY
GROUPING(category),
category

Результат:
category | total_revenue | orders_count
Не указана | 800 | 1 ← NULL из данных
Одежда | 7000 | 2
Обувь | 1200 | 1
Все категории | 10700 | 4 ← итог ROLLUP

Теперь всё на своих местах.

🟢 Хотите еще таких лайфхаков ?
🔥 Набираем 70 реакций на этот пост, чтобы подобные посты выходили чаще

Итог: 🤩

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓ А знали про ROLLUP и GROUPING() раньше? Делитесь в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit

1.2k 0 22 20 44

🏠 IT ипотека (Часть 1) — выбор города и района:

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

Почему вообще купил и зачем именно сейчас: 
Хотелось закрыть гештальт. Может, это и не самое выгодное финансовое решение, но психологически — точно правильное. Своя квартира = спокойствие (по крайней мере у меня так).

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

Что по итогу выбрал:
По итогу выбор пал на ЖК, который находится рядом с МЦД (в 10 минутах ходьбы). По отделке — это черновой вариант (стены и окна). White box оставались только трех-комнатные квартиры, что дорого и не ликвидно. Поскольку это черновой вариант решено было проектировать и разбираться во всем этом самостоятельно (благо есть знакомые и родственники с кем можно было советоваться). Подумал, что будет интересно под разобраться в этом (тем более по образованию я инженер-строитель) по этому в следующих постах буду рассказывать про ремонт, создание проекта, где я смог сэкономить и так далее.

🔥 Набираем 70 реакций на этот пост, чтобы посты про IT ипотеку выходили быстрее

Итог: 🤩


❓ А как вы относитесь к Ипотеке?
✔️ Подпишитесь на канал, чтобы не пропустить следующие посты.

🚬 Вопросы, менторство, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit


📊 SQL трюк — как добавить строку «Все категории» к любому отчёту через UNION ALL (ЧАСТЬ 1):

Ситуация, с которой многие сталкиваются на работе.
Давайте представим таблицу с продажами orders:
order_id | category | revenue
1 | Одежда | 1500
2 | Обувь | 1200
3 | Техника | 2500
4 | Одежда | 5500
.........

И нужно сделать отчёт по продажам, который будет показывать в разрезе категорий тотал продажи — и при этом должна быть отдельная категория, которая объединяла бы все остальные. Её как раз мы искусственно и добавим через UNION ALL.

🟢 Шаг 1 — обычная разбивка по категориям:
SELECT
category,
SUM(revenue) AS total_revenue,
COUNT(order_id) AS orders_count
FROM orders
GROUP BY category

Получаем это:
category | total_revenue | orders_count
Одежда | 7000 | 2
Обувь | 1200 | 1
Техника | 2500 | 1
Хорошо, но итога по всем нет. Добавляем его через UNION ALL.

🟢 Шаг 2 — добавляем строку «Все категории»:
SELECT
category,
SUM(revenue) AS total_revenue,
COUNT(order_id) AS orders_count
FROM orders
GROUP BY category

UNION ALL

SELECT
'Все категории' AS category,
SUM(revenue),
COUNT(order_id)
FROM orders

Результат:
category | total_revenue | orders_count
Одежда | 7000 | 2
Обувь | 1200 | 1
Техника | 2500 | 1
Все категории | 10700 | 4

Второй запрос считает тотал по всей таблице, а в поле category мы просто подставляем строку 'Все категории' — и она встаёт отдельной строкой в результате.

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

В нашем случае дублей нет — строка 'Все категории' явно уникальна.
Так что UNION тут ни к чему, берём UNION ALL — он быстрее.

🟢 Бонус — строка с тоталом всегда внизу:
WITH combined AS (
SELECT
category,
SUM(revenue) AS total_revenue,
COUNT(order_id) AS orders_count
FROM orders
GROUP BY category

UNION ALL

SELECT
'Все категории',
SUM(revenue),
COUNT(order_id)
FROM orders
)
SELECT *
FROM combined
ORDER BY
CASE WHEN category = 'Все категории' THEN 1 ELSE 0 END,
category

🟢 Хотите еще таких лайфхаков ?
🔥 Набираем 70 реакций на этот пост, чтобы подобные посты выходили чаще

Итог: 🤩

❤️ Поддержать канал бустами, чтобы у автора появился дополнительный функционал можно - здесь (это бесплатно и доступно с подпиской telegram premium)
❓ А какие ещё задачи решаете через UNION ALL — поделитесь в комментариях!
✔️ Подпишитесь на канал, чтобы не пропустить следующие хаки.


🚬 Вопросы, обучение, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit


🔐 SQL-инъекция — типы, примеры и защита: всё что нужно знать аналитику:

Один из вопросов, который может быть на собесе - это что такое "SQL-инъекция".
Давайте разберёмся, как обычно с кодом и без воды.

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

Бэкенд строит запрос прямо из того, что ввёл пользователь:
SELECT * FROM users
WHERE username = 'ВВОД' AND password = 'ВВОД';

Кавычки вокруг ввода уже вшиты в шаблон кода. Злоумышленник вводит admin' -- и запрос превращается в:
WHERE username = 'admin' --' AND password = '...';

Левая кавычка уже есть в шаблоне — злоумышленник дописывает только закрывающую '. Она обрывает строку досрочно, -- превращает всё остальное в комментарий. Проверка пароля выброшена — вход открыт.

🟢 3 основных типа SQL-инъекций:

1️⃣ Классическая — результат виден прямо в ответе сайта. Самый простой случай как выше.
2️⃣ Слепая (Blind) — сайт не выводит данные, но страница реагирует по-разному. Злоумышленник добавляет условие через AND к рабочему запросу:
SELECT * FROM products WHERE id = 1
AND SUBSTRING(password, 1, 1) = 'a'
Если буква угадана → TRUE AND TRUE → товар найден → страница загрузилась Если не угадана → TRUE AND FALSE → товар не найден → страница пустая
По реакции страницы злоумышленник понимает верна ли буква — как игра «горячо-холодно». Перебирает символ за символом.
3️⃣ Через UNION — дописывает свой SELECT к оригинальному и вытаскивает данные из любой таблицы. Структуру БД знать заранее не нужно — она вытаскивается через information_schema, системный справочник который есть в каждой БД:
-- Шаг 1: узнать все таблицы
' UNION SELECT table_name, null FROM information_schema.tables --

-- Шаг 2: узнать поля нужной таблицы
' UNION SELECT column_name, null FROM information_schema.columns
WHERE table_name = 'users' --

-- Шаг 3: вытащить данные
' UNION SELECT username, password FROM users --

🟢 Как защититься:

Без защиты Python склеивает строку и отдаёт в БД целиком — данные и команды уже неразличимы:
# ПЛОХО
query = "SELECT * FROM users WHERE username = '" + username + "'"

С параметрами шаблон и данные уходят в БД раздельно:
# ХОРОШО
cursor.execute(
"SELECT * FROM users WHERE username = %s",
(username,)
)

БД сначала получает шаблон → разбирает и фиксирует структуру запроса. Потом получает данные — и воспринимает их только как текст для поиска. Апостроф внутри admin' -- уже просто символ, а не SQL-синтаксис — структура зафиксирована и данные её изменить не могут.

🟢 Ответ на собесе — коротко:

«SQL-инъекция — это вид атаки, когда пользовательский ввод попадает напрямую в строку SQL-запроса и исполняется как код. Защита — параметризованные запросы: шаблон и данные идут в БД раздельно, поэтому данные никогда не интерпретируются как SQL-команды.»


Итог: 🤩


❓ Спрашивали про SQL-инъекцию на вашем собесе? Пишите в комментарии!
✔️ Подпишитесь на канал, чтобы не пропустить следующие посты.

🚬 Вопросы, менторство, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit

961 0 13 17 36

❤️ Переменные в SQL: один раз написал — везде обновилось

Вам знакома ситуация, когда - написал большой sql запрос для задачи, а потом заказчик говорит: «Покажи то же самое, но за прошлый квартал» ?
И вы начинаете искать дату по всему файлу. Находите все вхождения, правите — и где-то всё равно пропускаешь одно. Запрос считает не то.
В общем очень много рутины.

🟢 В Python мы бы написали переменную в начале и пере использовали ее везде:
start_date = "2024-01-01"
discount_threshold = 0.10

🟢 Но в SQL тоже можно кое что придумать:
WITH params AS (
SELECT
DATE '2024-01-01' AS period_start,
DATE '2024-03-31' AS period_end,
0.10 AS discount_threshold
),
big_orders AS (
SELECT
o.order_id,
o.amount,
o.discount
FROM orders o
CROSS JOIN params p
WHERE o.order_date BETWEEN p.period_start AND p.period_end
AND o.discount > p.discount_threshold
)
SELECT * FROM big_orders

Все параметры — в одном месте сверху. Поменял квартал один раз — везде пересчиталось.

CROSS JOIN здесь — это не страшно.
params возвращает одну строку.
CROSS JOIN просто «прицепляет» эту строку к каждой строке основной таблицы.

🟢 Хотите еще таких лайфхаков ?
🔥 Набираем 70 реакций на этот пост, чтобы подобные посты выходили чаще

Итог: 🤩

🗂 Это один из тех приёмов, который занимает 10 секунд, но экономит кучу времени на поддержке запроса.
❓ А как вы решаете эту проблему — хардкодите или есть другой подход? Пишите в комментах!
📤 Пересылай пост коллеге или другу из аналитики — это бесплатно и помогает каналу расти. Спасибо!


🚬 Вопросы, обучение, консультации: Написать в ЛС | mentor.dima-sqlit.ru


@dima_sqlit

1k 0 20 28 91
Показано 20 последних публикаций.