Задача: найти топ-2 Power Users в Microsoft Teams — пользователей, которые отправили больше всего сообщений в августе 2022. Вывести их
sender_id и количество сообщений.Подход:
1) Отфильтровать сообщения по интервалу августа — в T-SQL удобно задавать полуинтервалом
[2022-08-01, 2022-09-01), без функций над датой (чтобы не ломать индексы).2) Посчитать сообщения по
sender_id.3) Отсортировать по убыванию и взять TOP 2.
Если хотите корректно обрабатывать «ничьи» — используйте
DENSE_RANK().Быстрое решение (T-SQL):
SELECT TOP (2)
sender_id,
COUNT(*) AS message_count
FROM messages
WHERE sent_date >= '2022-08-01'
AND sent_date < '2022-09-01'
GROUP BY sender_id
ORDER BY COUNT(*) DESC, sender_id;
Вариант с учетом ничьих (tie-safe):
WITH monthly AS (
SELECT sender_id, COUNT(*) AS message_count
FROM messages
WHERE sent_date >= '2022-08-01'
AND sent_date < '2022-09-01'
GROUP BY sender_id
),
ranked AS (
SELECT sender_id, message_count,
DENSE_RANK() OVER (ORDER BY message_count DESC) AS rnk
FROM monthly
)
SELECT sender_id, message_count
FROM ranked
WHERE rnk <= 2
ORDER BY message_count DESC, sender_id;
Почему так:
- Фильтр по диапазону дат без функций сохраняет «sargable» запрос (используются индексы по sent_date).
- GROUP BY + COUNT(*) дают нужную метрику.
- DENSE_RANK() аккуратно захватывает все «совместные» вторые места.
@sqlhub
Please open Telegram to view this post
    VIEW IN TELEGRAM
  ❤10👍7🔥1
  🚀 Умная система мониторинга Alerta
Alerta — это масштабируемый инструмент мониторинга, который легко настраивается и принимает оповещения из различных источников. Он предлагает быструю визуализацию данных с возможностью глубокого анализа.
🚀 Основные моменты:
- Масштабируемая архитектура
- Минимальная конфигурация
- Поддержка MongoDB и PostgreSQL
- Удобная веб-консоль для визуализации
- Легкая интеграция с облачными платформами
📌 GitHub: https://github.com/alerta/alerta
#python
Alerta — это масштабируемый инструмент мониторинга, который легко настраивается и принимает оповещения из различных источников. Он предлагает быструю визуализацию данных с возможностью глубокого анализа.
🚀 Основные моменты:
- Масштабируемая архитектура
- Минимальная конфигурация
- Поддержка MongoDB и PostgreSQL
- Удобная веб-консоль для визуализации
- Легкая интеграция с облачными платформами
📌 GitHub: https://github.com/alerta/alerta
#python
👍6❤5🥰2
  This media is not supported in your browser
    VIEW IN TELEGRAM
  Игра не просто работает, а поддерживает многопользовательский режим, отрисовывая всё с помощью ASCII-графики.
Каждый компонент — от рендера до синхронизации игроков — написан исключительно на SQL-запросах.
🎮 GitHub для настоящих ценителей извращённого кода: https://github.com/cedardb/DOOMQL
@sqlhub
Please open Telegram to view this post
    VIEW IN TELEGRAM
  🤯22❤11👍5🥰2
  @sqlhub
Please open Telegram to view this post
    VIEW IN TELEGRAM
  👍6❤4🔥3
  Введение. Собеседования на позиции, связанные с данными (аналитики, инженеры, ученые данных), всё чаще включают нестандартные и продвинутые вопросы по SQL.
Большие технологические компании (Google, Amazon и др.) предъявляют высокие требования: важна не только правильность запроса, но и умение оптимизировать его и разбираться в реальных бизнес-данных.
В этом гайде мы разберем категории наиболее распространенных сложных SQL-задач с реальных собеседований – от платформ вроде DataLemur, LeetCode, StrataScratch – и подробно поясним решения.
Каждая задача сопровождена анализом: условие, оптимальный подход, используемые SQL-конструкции, возможные ошибки и финальное решение (для PostgreSQL и MySQL, с указанием различий где необходимо).
В конце добавлен отдельный раздел о современных базах данных, включая векторные БД (Pinecone, Weaviate, Milvus и др.), с примерами того, что могут спросить про них на собеседовании и как выглядят SQL-подобные запросы для работы с векторами.
📌 Читать гайд
Please open Telegram to view this post
    VIEW IN TELEGRAM
  👍15❤6🔥2
  🟡🔵 Разбираемся с SQL JOIN и фильтрами в OUTER JOIN
Одна из самых частых ошибок при работе с SQL - путаница между условием в
Когда мы пишем
✨ Пример:
У нас есть две таблицы:
- Левая: фигура + число
- Правая: число + фигура
Мы делаем
1. Фильтр в ON
Если написать
2. Фильтр в WHERE
Если написать
⚡ Почему это нужно знать?
-
-
- В
📌 Вывод:
- Если нужно оставить все строки из левой таблицы и лишь добавить совпадения справа - фильтр ставим в
- Если хотим действительно отобрать только подходящие строки — фильтр в
Именно поэтому в сложных запросах всегда спрашивай себя: фильтр — это часть логики соединения или это окончательное ограничение?
#SQL #joins #databases
Одна из самых частых ошибок при работе с 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
❤9👍9🔥5
  💡 SQL: использование оконных функций для накопительных сумм   
Хотите посчитать «бегущую сумму» или ранжирование без подзапросов?
Используйте
🔎 Здесь для каждого клиента мы получаем накопительную сумму по мере добавления заказов.
Оконные функции позволяют легко строить кумулятивные метрики, рейтинги и скользящие средние прямо в одном запросе.
@sqlhub
Хотите посчитать «бегущую сумму» или ранжирование без подзапросов?
Используйте
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
👍14❤4🔥2
  Собеседования на позицию разработчика больших языковых моделей (LLM) в топовых AI-компаниях предъявляют высокие требования к знаниям.
Кандидату необходимо понимать устройство архитектуры трансформеров, владеть методами эффективного обучения и инференса, разбираться в оптимизациях памяти и скорости (таких как LoRA, FlashAttention, vLLM, ZeRO), знать тонкости распределённого тренинга, принципов LLMOps (MLOps для больших моделей) и нюансов продакшн-развертывания LLM.
Также часто проверяют умение решать реальные задачи: от проектирования пайплайна для Sparse MoE до анализа проблем с памятью на GPU, понимания различий между методами обучения с подкреплением (RLHF vs DPO) и способов масштабирования моделей.
Этот гайд структурирован по ключевым темам, соответствующим областям знаний, которые обычно проверяются на собеседованиях. Для каждой темы мы рассмотрим, что пытаются проверить интервьюеры, приведём пример формулировки вопроса и дадим подробный разбор ответа с обсуждением трэйд-оффов, примеров кода или схем, где это уместно. Вы можете изучать материал по разделам, чтобы сфокусироваться на интересующей области.
👉 Гайд
Please open Telegram to view this post
    VIEW IN TELEGRAM
  ❤5👍1🔥1
  💡 SQL: быстрое нахождение первых или последних записей с DISTINCT ON !!!  
В PostgreSQL есть полезный приём —
🔎 Этот запрос вернёт последний заказ каждого клиента без лишних подзапросов или JOIN.
⚡ Работает очень быстро и удобно, если нужно найти «самый первый» или «самый последний» элемент в группе.
@sqlhub
В PostgreSQL есть полезный приём —
DISTINCT ON, который позволяет взять первую строку в каждой группе по определённому полю.  
SELECT DISTINCT ON (customer_id)
customer_id,
order_date,
amount
FROM orders
ORDER BY customer_id, order_date DESC;
🔎 Этот запрос вернёт последний заказ каждого клиента без лишних подзапросов или JOIN.
⚡ Работает очень быстро и удобно, если нужно найти «самый первый» или «самый последний» элемент в группе.
@sqlhub
🔥27❤8👍7🥰1
  🗄️ Неочевидный SQL-совет  
Иногда нужно выбрать строки с первыми или последними значениями внутри группы — например, последний заказ каждого клиента.
Вместо вложенных подзапросов используйте
👉 Результат: по каждому customer_id вернётся только одна строка — с самым свежим заказом.
Очень компактная и быстрая альтернатива оконным функциям или JOIN-ам.
Иногда нужно выбрать строки с первыми или последними значениями внутри группы — например, последний заказ каждого клиента.
Вместо вложенных подзапросов используйте
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-ам.
❤24👍4🔥3
  💡Неочевидный SQL-совет  
Часто нужно выбрать топ-N строк внутри каждой группы — например, два самых дорогих товара в категории.
Вместо сложных оконных функций можно использовать
👉 Результат: по каждой категории вернутся только два товара с наибольшей ценой.
Этот приём делает запрос короче и понятнее, убирая необходимость во вложенных подзапросах. Если вы используете СУБД с поддержкой QUALIFY, берите на вооружение.
Часто нужно выбрать топ-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, берите на вооружение.
👍14🤔2❤1
  🚀 SQL Ultimate Course — бесплатный полный курс по SQL на GitHub  
Если хочешь освоить SQL с нуля и дойти до продвинутого уровня — бери готовый репозиторий:
📂 Что внутри:
- datasets/ — реальные данные из ERP и CRM
- scripts/ — готовые SQL-скрипты для практики
- docs/ — документация и материалы курса
✅ MIT-лицензия — можно использовать и менять свободно
🌍 Подходит для всех СУБД (PostgreSQL, MySQL и др.)
🎥 К курсу прилагаются видео и гайды от автора
Автор: Data With Baraa — практик и ютубер, собравший в одном месте полный SQL-путь от простого
🔗 Репозиторий здесь: https://github.com/DataWithBaraa/sql-ultimate-course
Сохраняй, проходи и прокачивай SQL 💡
@sqlhub
Если хочешь освоить SQL с нуля и дойти до продвинутого уровня — бери готовый репозиторий:
📂 Что внутри:
- datasets/ — реальные данные из ERP и CRM
- scripts/ — готовые SQL-скрипты для практики
- docs/ — документация и материалы курса
✅ MIT-лицензия — можно использовать и менять свободно
🌍 Подходит для всех СУБД (PostgreSQL, MySQL и др.)
🎥 К курсу прилагаются видео и гайды от автора
Автор: Data With Baraa — практик и ютубер, собравший в одном месте полный SQL-путь от простого
SELECT до оптимизации запросов и реальных кейсов.  🔗 Репозиторий здесь: https://github.com/DataWithBaraa/sql-ultimate-course
Сохраняй, проходи и прокачивай SQL 💡
@sqlhub
❤9👍5🔥4
  ⚡️ Предотвращаем потерю данных с ACID-транзакциями в DuckDB!  
❌ Без транзакций:
- Списание у Alice прошло ✅
- Пополнение у Bob сломалось ❌
➡️ Итог: деньги «пропали».
✅ С транзакцией (ACID):
- Оба обновления либо проходят вместе, либо откатываются
- Баланс остаётся консистентным
- Никаких «висящих» операций
Пример:
🔹 Atomicity — либо всё, либо ничего
🔹 Consistency — база не ломается
🔹 Isolation — параллельные операции не мешают
🔹 Durability — данные не теряются
🛡 ACID гарантирует надёжность даже при сбоях.
❌ Без транзакций:
- Списание у 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 гарантирует надёжность даже при сбоях.
👍10❤6🥰3🤔1🤬1
  🚀 Вышел Postgres 18 — с поддержкой Async I/O  
Раньше все операции чтения были блокирующими, теперь - нет.
Результат: огромный прирост производительности для приложений с интенсивным чтением.
⚡️ Async I/O включён по умолчанию в Postgres 18!
Что интересного:
- Новый алгоритм skip scan для многостолбцовых индексов
- Параллельное построение GIN-индексов (JSON, полнотекст)
- Виртуальные генерируемые столбцы (значения считаются на лету)
- Функция
- Сохранение статистики планировщика при мажорных апгрейдах
- Поддержка OAuth 2.0, улучшения TLS и безопасности
- Новый протокол взаимодействия клиентов и утилит — v3.2
🟠  Релиз: https://www.postgresql.org/about/news/postgresql-18-released-3142/
@sqlhub
Раньше все операции чтения были блокирующими, теперь - нет.
Результат: огромный прирост производительности для приложений с интенсивным чтением.
⚡️ Async I/O включён по умолчанию в Postgres 18!
Что интересного:
- Новый алгоритм skip scan для многостолбцовых индексов
- Параллельное построение GIN-индексов (JSON, полнотекст)
- Виртуальные генерируемые столбцы (значения считаются на лету)
- Функция
uuidv7() — UUID с временной сортировкой  - Сохранение статистики планировщика при мажорных апгрейдах
- Поддержка OAuth 2.0, улучшения TLS и безопасности
- Новый протокол взаимодействия клиентов и утилит — v3.2
@sqlhub
Please open Telegram to view this post
    VIEW IN TELEGRAM
  ❤16👍11🔥8
  Когда вы пишете юнит-тесты, подключение к реальной БД — лишнее:
- это медленно,
- тесты становятся нестабильными,
- нужен живой сервер.
Решение — замокать вызов
pandas.read_sql и вернуть подставные данные.Пример функции:
def query_user_data(user_id):
query = f"SELECT id, name FROM users WHERE id = {user_id}"
return pd.read_sql(query, "postgresql://localhost/mydb")
Тест с моком:
from unittest.mock import patch
import pandas as pd
@patch("pandas.read_sql")
def test_database_query_mocked(mock_read_sql):
mock_read_sql.return_value = pd.DataFrame(
{"id": [123], "name": ["Alice"]}
)
result = query_user_data(user_id=123)
assert result["name"].iloc[0] == "Alice"
Теперь вместо запроса в реальную базу тест подставляет фейковые данные. Так можно проверить бизнес-логику функции быстро и надёжно.
@sqlhub
Please open Telegram to view this post
    VIEW IN TELEGRAM
  👍14❤6😁1
  Если строишь чат-бота или RAG-систему — Chroma даст твоему приложению память и быстрый поиск по векторным представлениям.
✨ Что умеет:
- Поддержка Python и JavaScript
- Быстрый поиск и фильтрация по embeddings
- Интеграция с LangChain и LlamaIndex
- Простое API для добавления документов и метаданных
🚀 Установка:
pip install chromadb
# или
npm install chromadb
chroma run --path ./chroma_db
🧩 Пример на Python:
import chromadb
client = chromadb.Client()
col = client.create_collection("docs")
col.add(documents=["Doc1","Doc2"], ids=["1","2"])
res = col.query(query_texts=["найди похожее"], n_results=1)
▪Github
▪Colab
Please open Telegram to view this post
    VIEW IN TELEGRAM
  👍6❤3
  🟠 ParadeDB — альтернатива Elasticsearch на базе PostgreSQL
В эпоху data-driven решений поиск и аналитика в реальном времени стали обязательной частью любой стратегии.
ParadeDB — это новый open-source игрок: расширение для PostgreSQL, превращающее его в мощный движок полнотекстового поиска и аналитики.
✨ Возможности:
Реал-тайм поиск по данным прямо в Postgres
Высокая производительность без внешних сервисов
Open-source и легко встраивается в существующую инфраструктуру
🔗 Подробнее: blackslate.io/articles/paradedb-an-elasticsearch-alternative-built-on-postgresql
@sqlhub
В эпоху data-driven решений поиск и аналитика в реальном времени стали обязательной частью любой стратегии.
ParadeDB — это новый open-source игрок: расширение для PostgreSQL, превращающее его в мощный движок полнотекстового поиска и аналитики.
✨ Возможности:
Реал-тайм поиск по данным прямо в Postgres
Высокая производительность без внешних сервисов
Open-source и легко встраивается в существующую инфраструктуру
🔗 Подробнее: blackslate.io/articles/paradedb-an-elasticsearch-alternative-built-on-postgresql
@sqlhub
❤7
  ⚠️ SQL-инъекция через f-string  
Если подставлять значения прямо в SQL через f-string, злоумышленник может выполнить любой код в базе:
💥 И вот таблица accounts удалена!
Почему так?
Потому что строка с именем вставляется как есть и воспринимается как часть SQL-запроса.
✅ Правильный способ — использовать параметры:
✔ Имя ищется как текст, база остаётся в безопасности.
👉 Запомни: никогда не вставляй пользовательские данные напрямую в SQL.
Используй параметризованные запросы — это надёжная защита от SQL-инъекций.
@sqlhub
Если подставлять значения прямо в 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
👍18🔥6❤5
  Знали ли вы, что у SQLite есть векторное расширение? 🧮
SQLite - самая используемая база данных в мире, работает практически на любом устройстве.
Теперь можно легко строить AI-приложения с помощью SQLite-vec и новой Embedding Gemma прямо на устройстве, без интернета.
На скрине - простой пример с Python + SQLite и Ollama. SQLite-vec совместим с WASM и запускается где угодно. Пример можно адаптировать почти под любой язык: Swift, Kotlin, Java, JavaScript…
🟢 Script: https://github.com/philschmid/gemini-samples/blob/main/scripts/embeddinggemma-sqlite-ollama.py
🟢 Sqlite-vec:  https://alexgarcia.xyz/sqlite-vec/
🟢 EmbeddingGemma: https://developers.googleblog.com/en/introducing-embeddinggemma/
@sqlhub
SQLite - самая используемая база данных в мире, работает практически на любом устройстве.
Теперь можно легко строить AI-приложения с помощью SQLite-vec и новой Embedding Gemma прямо на устройстве, без интернета.
На скрине - простой пример с Python + SQLite и Ollama. SQLite-vec совместим с WASM и запускается где угодно. Пример можно адаптировать почти под любой язык: Swift, Kotlin, Java, JavaScript…
@sqlhub
Please open Telegram to view this post
    VIEW IN TELEGRAM
  👍6❤3🔥2
  Отличный курс для тех, кто хочет разобраться в нейронках с нуля от Андрея Карпати (OpenAI/Tesla).
Внутри бесплатная серия лекций на YouTube (и репа на GitHub), где ты с нуля учишься собирать нейронки. Всё максимально hands-on:
Автор не просто рассказывает теорию, а пишет код вместе с тобой — от самых азов до тренировки сетей.
https://github.com/karpathy/nn-zero-to-hero/
Внутри бесплатная серия лекций на YouTube (и репа на GitHub), где ты с нуля учишься собирать нейронки. Всё максимально hands-on:
Автор не просто рассказывает теорию, а пишет код вместе с тобой — от самых азов до тренировки сетей.
https://github.com/karpathy/nn-zero-to-hero/
❤15🔥8👍5
  