🟡🔵 Разбираемся с SQL JOIN и фильтрами в OUTER JOIN

Одна из самых частых ошибок при работе с SQL - путаница между условием в ON и фильтром в WHERE. На картинке это отлично показано.

Когда мы пишем LEFT OUTER JOIN, мы ожидаем, что слева попадут все строки. Но результат зависит от того, где именно мы накладываем фильтры.

✨ Пример:

У нас есть две таблицы:
- Левая: фигура + число
- Правая: число + фигура

Мы делаем LEFT OUTER JOIN.

1. Фильтр в ON
Если написать ON right_table.number = 1, то соединение будет проверять условие именно во время джойна. Это значит: строки слева сохранятся, даже если справа нет совпадений — просто будут NULL.

2. Фильтр в WHERE
Если написать WHERE left_table.number = 1, то фильтрация произойдёт уже после объединения. В этом случае строки, не прошедшие условие, полностью исчезнут из результата.

⚡ Почему это нужно знать?

- ON управляет логикой соединения.
- WHERE убирает строки после соединения.
- В OUTER JOIN это принципиальная разница: при фильтре в ON мы сохраним «пустые» строки, при фильтре в WHERE они будут удалены.


📌 Вывод:
- Если нужно оставить все строки из левой таблицы и лишь добавить совпадения справа - фильтр ставим в ON.
- Если хотим действительно отобрать только подходящие строки — фильтр в WHERE.

Именно поэтому в сложных запросах всегда спрашивай себя: фильтр — это часть логики соединения или это окончательное ограничение?

#SQL #joins #databases

💡 SQL: использование оконных функций для накопительных сумм

Хотите посчитать «бегущую сумму» или ранжирование без подзапросов?
Используйте WINDOW FUNCTIONS — они считаются построчно, не сворачивая данные.

SELECT 
    customer_id,
    order_date,
    amount,
    SUM(amount) OVER (
        PARTITION BY customer_id 
        ORDER BY order_date
    ) AS running_total
FROM orders;

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

@sqlhub

💡 SQL: быстрое нахождение первых или последних записей с DISTINCT ON !!!

В PostgreSQL есть полезный приём — DISTINCT ON, который позволяет взять первую строку в каждой группе по определённому полю.

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

🔎 Этот запрос вернёт последний заказ каждого клиента без лишних подзапросов или JOIN.

⚡ Работает очень быстро и удобно, если нужно найти «самый первый» или «самый последний» элемент в группе.

@sqlhub

🗄️ Неочевидный SQL-совет

Иногда нужно выбрать строки с первыми или последними значениями внутри группы — например, последний заказ каждого клиента.
Вместо вложенных подзапросов используйте DISTINCT ON (PostgreSQL):

SELECT DISTINCT ON (customer_id) 
       customer_id, order_id, created_at
FROM orders
ORDER BY customer_id, created_at DESC;

👉 Результат: по каждому customer_id вернётся только одна строка — с самым свежим заказом.
Очень компактная и быстрая альтернатива оконным функциям или JOIN-ам.

💡Неочевидный SQL-совет

Часто нужно выбрать топ-N строк внутри каждой группы — например, два самых дорогих товара в категории.
Вместо сложных оконных функций можно использовать QUALIFY (в Snowflake, BigQuery, DuckDB, Trino):

SELECT category_id, product_id, price
FROM products
QUALIFY ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY price DESC) <= 2;

👉 Результат: по каждой категории вернутся только два товара с наибольшей ценой.

Этот приём делает запрос короче и понятнее, убирая необходимость во вложенных подзапросах. Если вы используете СУБД с поддержкой QUALIFY, берите на вооружение.

🚀 SQL Ultimate Course — бесплатный полный курс по SQL на GitHub

Если хочешь освоить SQL с нуля и дойти до продвинутого уровня — бери готовый репозиторий:

📂 Что внутри:
- datasets/ — реальные данные из ERP и CRM
- scripts/ — готовые SQL-скрипты для практики
- docs/ — документация и материалы курса

✅ MIT-лицензия — можно использовать и менять свободно
🌍 Подходит для всех СУБД (PostgreSQL, MySQL и др.)
🎥 К курсу прилагаются видео и гайды от автора

Автор: Data With Baraa — практик и ютубер, собравший в одном месте полный SQL-путь от простого SELECT до оптимизации запросов и реальных кейсов.

🔗 Репозиторий здесь: https://github.com/DataWithBaraa/sql-ultimate-course

Сохраняй, проходи и прокачивай SQL 💡

@sqlhub

⚡️ Предотвращаем потерю данных с ACID-транзакциями в DuckDB!

❌ Без транзакций:
- Списание у Alice прошло ✅
- Пополнение у Bob сломалось ❌
➡️ Итог: деньги «пропали».

✅ С транзакцией (ACID):
- Оба обновления либо проходят вместе, либо откатываются
- Баланс остаётся консистентным
- Никаких «висящих» операций

Пример:

conn.execute("BEGIN TRANSACTION")
try:
    conn.execute("UPDATE accounts SET balance = balance - 200 WHERE name = 'Alice'")
    conn.execute("UPDATE accounts SET balance = balance + 200 WHERE name = 'Bob'")
    conn.execute("COMMIT")
except:
    conn.execute("ROLLBACK")

🔹 Atomicity — либо всё, либо ничего
🔹 Consistency — база не ломается
🔹 Isolation — параллельные операции не мешают
🔹 Durability — данные не теряются

🛡 ACID гарантирует надёжность даже при сбоях.

🟠 ParadeDB — альтернатива Elasticsearch на базе PostgreSQL

В эпоху data-driven решений поиск и аналитика в реальном времени стали обязательной частью любой стратегии.
ParadeDB — это новый open-source игрок: расширение для PostgreSQL, превращающее его в мощный движок полнотекстового поиска и аналитики.

✨ Возможности:

Реал-тайм поиск по данным прямо в Postgres

Высокая производительность без внешних сервисов

Open-source и легко встраивается в существующую инфраструктуру

🔗 Подробнее: blackslate.io/articles/paradedb-an-elasticsearch-alternative-built-on-postgresql

@sqlhub

⚠️ SQL-инъекция через f-string

Если подставлять значения прямо в SQL через f-string, злоумышленник может выполнить любой код в базе:

name = "Alice'; DROP TABLE accounts; --"
query = f"SELECT * FROM accounts WHERE name = '{name}'"
conn.sql(query)

💥 И вот таблица accounts удалена!

Почему так?

Потому что строка с именем вставляется как есть и воспринимается как часть SQL-запроса.

✅ Правильный способ — использовать параметры:

name = "Alice'; DROP TABLE accounts; --"
query = "SELECT * FROM accounts WHERE name = ?"
conn.sql(query, params=(name,))

✔ Имя ищется как текст, база остаётся в безопасности.

👉 Запомни: никогда не вставляй пользовательские данные напрямую в SQL.

Используй параметризованные запросы — это надёжная защита от SQL-инъекций.

@sqlhub

Отличный курс для тех, кто хочет разобраться в нейронках с нуля от Андрея Карпати (OpenAI/Tesla).

Внутри бесплатная серия лекций на YouTube (и репа на GitHub), где ты с нуля учишься собирать нейронки. Всё максимально hands-on:

Автор не просто рассказывает теорию, а пишет код вместе с тобой — от самых азов до тренировки сетей.

https://github.com/karpathy/nn-zero-to-hero/

🌐 OrbitDB — распределённая serverless P2P-база данных для децентрализованных приложений

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

⚙️ Основные принципы:
- IPFS — хранение данных.
- Libp2p Pubsub — репликация и синхронизация между узлами.
- Merkle-CRDT — гарантирует бесконфликтные записи и объединение данных в условиях многоверсионности.

📊 Типы БД:
- Журнал событий (append-only log)
- Key-Value store
- Документная база
- Индексируемые коллекции

Все они построены на иммутабельном OpLog, который обеспечивает eventual consistency без выделенного сервера.

📌 Github

Новое техношоу о фейлах на дата-платформах

Все упало, все сломалось, бизнес в панике. Для дата-инженеров это обычный вторник, а для шоу «Дропнуто» — повод снять свежий выпуск.

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

Анонсы и ссылки на прямые эфиры появятся в телеграм-боте проекта.

Подписывайтесь, чтобы узнавать о премьерах первыми.

💾 Зачем нужен Delta Lake, если есть Parquet

Обычный Parquet хранит только одно состояние таблицы.
Если вы сохранили отфильтрованный DataFrame, то старые данные исчезли навсегда.
❌ Отката (rollback) нет → потеряли 10 000 строк, осталось только 3 500.

⚡ Delta Lake работает иначе:
- каждый раз создаётся новая версия данных
- можно вернуться к любой версии в прошлом
- данные всегда под контролем и без потерь

📌 Пример:
- Parquet → фильтр → оригинал стёрт
- Delta Lake → версия 0 (10 000 строк) + версия 1 (3 500 строк) → всегда можно вернуться к версии 0

✅ Итог: с Delta Lake данные становятся версионируемыми и надёжными.



#datalake #parquet #bigdata #delta