SQL начинается с SELECT, но логика запроса — с FROM

Логический порядок обработки запроса:

• FROM / JOIN — определить источники и объединить таблицы.
• WHERE — отфильтровать строки.
• GROUP BY — сформировать группы.
• HAVING — отфильтровать группы.
• SELECT — вычислить выражения и выбрать столбцы.
• DISTINCT — убрать дубликаты, если указан.
• ORDER BY — отсортировать результат.
• LIMIT / OFFSET — ограничить выдачу и пропустить строки.

Поэтому псевдоним из SELECT обычно доступен в ORDER BY, но не в WHERE: на этапе фильтрации он ещё не определён.

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

👉 @SQLPortal

SQL — это набор взаимосвязанных инструментов для работы с данными.

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

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

👉 @SQLPortal

SQL, Pandas и Power BI: 10 операций для работы с данными

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

Сравните подходы, чтобы понять общую логику операций и легче переключаться между SQL, Pandas и Power BI.

👉 @SQLPortal

Аналитика данных строится на простом процессе:

Сначала данные извлекаются, преобразуются и загружаются с помощью ETL. Затем их обработка организуется в data pipelines (конвейеры данных), ошибки и неточности устраняются до начала анализа.

После этого с помощью Data Mining (интеллектуального анализа данных) в больших наборах данных выявляются закономерности, тенденции и полезные инсайты.

👉 @SQLPortal

Кэш ускоряет приложение, но ошибки в кэшировании снижают его надёжность.

Частые антипаттерны:

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

• Не задавать TTL. Без срока действия или надёжной инвалидации устаревшие значения могут оставаться в кэше неограниченно долго.

• Обновлять БД и кэш без согласованной стратегии. Одна запись проходит, другая падает — данные расходятся. Продумайте порядок обновления, инвалидацию и обработку сбоев: write-through и write-behind сами по себе не гарантируют согласованность.

• Не учитывать отказ кэша. Предусмотрите резервный сценарий. Но помните: переключение всего трафика на БД может перегрузить её — нужны ограничения нагрузки.

• Не планировать инвалидацию. Заранее решите, когда удалять или обновлять записи и как распространять изменения между экземплярами приложения.

В архитектуре, где БД — источник истины, кэш должен ускорять доступ к данным, а не определять их корректность.

👉 @SQLPortal

SQL или Python для анализа данных? Освойте оба.

SQL удобен для выборки, фильтрации, объединения и агрегации данных в БД. Python — для очистки, исследовательского анализа, автоматизации и сложных вычислений.

Эти инструменты дополняют друг друга: подготовьте выборку с помощью SQL, а затем исследуйте и визуализируйте её в Python.

👉 @SQLPortal

Что происходит между GET /users/123 и ответом API?

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

В статье разобран путь запроса в приложении на Spring Boot:

• DNS и TLS.
• Балансировка нагрузки.
• Spring Security и JWT.
• Попадание и промах кэша Redis.
• Ожидание соединения из пула.
• Запросы к PostgreSQL.
• Взаимодействие с Kafka.
• Источники задержек на каждом этапе.

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

Читать на Medium

👉 @SQLPortal

Бесплатная база по работе с данными

Книга создателя pandas с подробным разбором NumPy, pandas, очистки данных, визуализации и временных рядов. Весь материал сопровождается практическими примерами, исходники и датасеты доступны на GitHub.

https://wesmckinney.com/book/

👉 @SQLPortal

Большая коллекция из практических рекомендаций по защите приложений. Внутри: SQL Injection, XSS, JWT, OAuth2, Kubernetes, Docker, API Security, а теперь ещё и безопасность агентов MCP и RAG.

https://cheatsheetseries.owasp.org

👉 @SQLPortal

Steampipe: SQL-запросы к облачной инфраструктуре

Какие ресурсы остались без обязательных тегов? Есть ли публично доступные S3-бакеты? В каких Kubernetes namespaces отсутствуют NetworkPolicies?

Для ответа необязательно переключаться между консолями и писать отдельные скрипты. Steampipe — open-source инструмент, который позволяет запрашивать данные из AWS, Kubernetes и других сервисов с помощью SQL.

Через плагины он обращается к API сервисов и представляет данные в виде таблиц. Можно фильтровать ресурсы, объединять результаты и проверять инфраструктуру привычными запросами.

Полезен для инвентаризации, поиска ошибок конфигурации и разовых проверок безопасности.

Руководство по Steampipe

👉 @SQLPortal

Партиционирование и шардинг: в чём разница?

Оба подхода делят данные на части, но решают разные задачи. Партиционирование — разделение одной логической таблицы на секции. В типичном случае они находятся в одной СУБД и используют ресурсы одного сервера.

Основные способы:

• Range — по диапазонам, например заказы по годам.
• List — по заданным значениям, например регионам US, EU и APAC.
• Hash — по хешу ключа распределения.

Если условия запроса позволяют, СУБД исключает ненужные секции из обработки — это называется partition pruning. Вместо всей таблицы читается только подходящая часть.

Партиционирование упрощает обслуживание, загрузку и удаление старых данных. Но ускорение зависит от запросов и ключа разбиения: само по себе оно не делает любой запрос быстрее. Устройство индексов тоже зависит от СУБД: они могут быть локальными или глобальными.

Шардинг — распределение данных между несколькими узлами или базами. Каждый шард использует собственные вычислительные ресурсы и хранилище. Например, клиентов распределяют по хешу customer_id. Приложение, прокси или сама распределённая СУБД определяет, куда отправить запрос. Если ключ шарда неизвестен, может потребоваться обращение к нескольким шардам.

Шардинг позволяет распределить нагрузку и объём данных, но усложняет:

• JOIN между шардами;
• транзакции, затрагивающие несколько узлов;
• перераспределение данных;
• борьбу с перегруженными шардами;
• маршрутизацию и эксплуатацию.

Эти подходы можно сочетать: таблицы внутри каждого шарда тоже могут быть партиционированы.

Обязательной цепочки «одна БД → партиции → реплики → шардинг» нет. Решение выбирают по узкому месту: объёму данных, нагрузке на чтение и запись, требованиям к задержкам и обслуживанию.

👉 @SQLPortal

8 приёмов очистки данных в SQL

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

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

👉 @SQLPortal

SQL, Python и PySpark: 50 операций с данными в сравнении

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

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

👉 @SQLPortal