Что делают AND и OR

• AND — «и». Все условия должны быть выполнены одновременно.
  Пример: выбрать из холодильника молоко и яйца, чтобы приготовить омлет:

SELECT *

FROM fridge

WHERE product = 'milk' AND product = 'eggs';

(Да, в реальности одной строки с молоком и яйцом не будет, но идея ясна: оба условия должны выполняться вместе.)

OR — «или». Достаточно, чтобы выполнено было хотя бы одно условие.
Пример: выбрать продукты, которые нужно купить или молоко, или яйца:

SELECT *

FROM shopping_list

WHERE product = 'milk' OR product = 'eggs';

Где могут использоваться

Эти операторы обычно используют в блоке WHERE, чтобы фильтровать данные.
Также можно применять их в:

• HAVING — фильтрация агрегатов после GROUP BY

• JOIN ON — комбинирование условий соединения таблиц

Пример с HAVING:

SELECT category, COUNT(*)

FROM fridge

GROUP BY category

HAVING COUNT(*) > 5 AND AVG(expiry_date) < '2025-08-01';

Особенности и нюансы:

• Порядок выполнения важен

  AND имеет более высокий приоритет, чем OR.

  Если смешиваете их, всегда используйте скобки для точного порядка:

  SELECT *

  FROM fridge

  WHERE (product = 'milk' OR product = 'eggs') AND expiry_date < '2025-08-01';

• AND «сжимает» результат, OR «расширяет» результат

  AND оставляет меньше строк, OR — больше

Частые ошибки

• Забыли скобки и получили слишком большой или слишком маленький результат

• Использовали AND там, где нужен OR (или наоборот)

• Смешали NULL значения: NULL AND TRUE и NULL OR TRUE могут вести себя неожиданно

Представим, что мама проверяет холодильник:

• У неё есть список продуктов, которые могут испортиться: молоко, яйца, йогурт

• Она хочет приготовить что-то, если и молоко, и яйца в наличии → AND

• Она хочет перекусить, если есть молоко или йогурт → OR

В SQL это выглядит так:

-- Для приготовления омлета

SELECT *

FROM fridge

WHERE product = 'milk' AND product = 'eggs';

-- Для перекуса

SELECT *

FROM fridge

WHERE product = 'milk' OR product = 'yogurt';

AND и OR — это простые, но мощные инструменты фильтрации. Правильное использование скобок и понимание приоритета операторов помогает избежать ошибок и выбирать точно те данные, которые нужны.

Вот тут и появляется WHERE. Это фильтр, который помогает выбрать именно нужные строки из таблицы — или продукты из холодильника.

А в своем канале На связи: SQL я публикую информацию с особенностями и нюансами в языке SQL, разбираю аналитические запросы и подходы работы с данными. Канал создала недавно с нулем подписчиков, но там уже есть интересная информация для работы аналитиков. Подписывайся!

Нам нужно выкинуть все продукты, у которых истек срок годности:

SELECT *
FROM fridge
WHERE expiry_date < CURRENT_DATE;

fridge — наша таблица с продуктами
expiry_date < CURRENT_DATE — условие: выбираем просроченные продукты
CURRENT_DATE - текущая дата

Что можно писать в WHERE

• Сравнения: =, >, <, >=, <=

• Логические связки: AND, OR, NOT

• Проверки на вхождение: IN, BETWEEN, LIKE

• Подзапросы: «проверить список покупок перед выбором»

Или, мы хотим приготовить что-то на десерт:

SELECT *
FROM fridge
WHERE category = 'dessert' AND expiry_date > CURRENT_DATE;

Условие AND expiry_date > CURRENT_DATE добавляем на случай, если мы не выкинули всю просрочку до этого.

Подзапросы

В WHERE можно использовать подзапросы. Это когда нам нужна информация из другого источника, чтобы использовать ее в своем запросе. Например, нам надо понять что из рецепта отсутствует у нас в холодильнике.

SELECT *
FROM cooking_recipe
WHERE product NOT IN (SELECT product FROM fridge);

WHERE проверяет какие продукты отсутствуют в холодильнике.

Аналогично можно использовать EXISTS или NOT EXISTS
SELECT *
FROM fridge f
WHERE EXISTS (SELECT 1 FROM cooking_recipe s WHERE s.product = f.product);

EXISTS = есть продукт в списке
NOT EXISTS = нет продукта в списке

ANY \ ALL

Эти конструкции позволяют сравнивать с набором значений.

SELECT *
FROM fridge
WHERE expiry_date <= ALL (SELECT expiry_date FROM fridge WHERE category = 'milk');

Все хорошие домохозяйки используют принцип ротации. Выбирают продукты, срок годности которых меньше всех в категории “молоко”.

• Подзапрос (SELECT expiry_date FROM fridge WHERE category = 'milk') возвращает даты всех банок молока.

• Условие expiry_date <= ALL (...) означает: выбрать только те банки, у которых дата годности меньше или равна каждой другой банке молока.

• Практически это банка (или несколько, если даты совпадают), которая старше всех остальных.

То есть, результат будет одна или несколько банок с самой ранней датой годности.

SELECT *
FROM fridge
WHERE expiry_date <= ANY (SELECT expiry_date FROM fridge WHERE category = 'milk');

• Условие expiry_date <= ANY (...) означает: выбрать все банки молока, у которых дата годности меньше или равна хотя бы одной другой банке молока.

• Тут почти все банки проходят условие, кроме самой свежей (если она самая большая по сроку).

• Результат может быть несколько банок, не обязательно только одна. Все, кто «моложе или равны хотя бы одной другой», будут выбраны.

CASE в WHERE

Можно использовать CASE для сложной логики

SELECT *
FROM fridge
WHERE
CASE
WHEN product = 'milk' THEN shelf = 'top'
ELSE shelf = 'middle'
END;

Если я ищу молочные продукты в холодильнике, то должна их искать на самой верхней полке, иначе - на средней.

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

Чем больше нагрузка и больше одновременно выполняющихся транзакций, тем больше и ответственности при создании хранимых функций и процедур. Хорошо написанный программный код легко сопровождаем и не боится параллельной работы! Ниже собрал для вас основные рекомендации, которые важно учитывать при разработке хранимок (функций, процедур, триггеров).

1. Максимально эффективное обращение к данных (желательно всегда по первичным ключам и индексам);

2. Разделение сложных операций на более простые (сложный update, insert или delete с подзапросами можно упростить - сделать его по ключу, а данные, получаемые подзапросами, можно предварительно положить во временную таблицу или таблицу временного хранения данных);

3. Соблюдение идентичной последовательности работы с таблицами в разных функциях и процедурах (это позволит минимизировать вероятность взаимных блокировок);

4. Форматирование кода (соблюдение отступов, единое оформление, принятое в компании или в конкретной АС), использование регламентов оформления кода;

5. Соблюдение соответствия программы кода хранимки её назначению (процедура, открывающая вклад клиенту, должна открывать вклад клиенту и не должна дополнительно закрывать кредит);

6. Краткое и понятное комментирование неочевидных участков кода;

7. Идеальный код одной хранимки помещается на одном экране, чтобы не пришлось его прокручивать (конечно, на практике, это далеко не всегда так, но надо к этому стремиться). Если алгоритм большой, то его нужно разбивать на дополнительные функции и процедуры, которые можно использовать в коде основной функции/процедуры.

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

SELECT — какие поля выбрать

FROM — из какой таблицы

JOIN — если нужно соединение

WHERE — фильтрация строк до агрегации

GROUP BY — группировка

HAVING — фильтрация групп (после агрегации)

ORDER BY — сортировка

LIMIT — ограничение количества строк

SELECT — это конструктор. Ты как будто сначала берёшь детали, потом отбираешь нужные, потом собираешь по группам, и только потом смотришь итог.

Мы привыкли, что текст читается слева направо, сверху вниз. Но не везде так:

• в арабском и иврите — читают справа налево,

• в китайском — традиционно писали сверху вниз.

Это не ошибка, не странность, а особенность языка, которая исторически так сложилась.

SQL — тоже «язык», и у него есть свои правила: мы пишем запрос сверху вниз, начиная с SELECT
А выполняется сам запрос совсем в другом порядке.

Об этом уже есть пост в моем новом канале На связи: SQL. Это канал про нюансы SQL, практические задачки и многое другое, что связано с аналитикой. Его я создала недавно абсолютно с нуля. Так что, если интересно, то подписывайся. А вот и ссылка на пост про последовательность выполнения запросов.

Где ещё встречается разница между тем, как пишут и как «читают»:

• Музыка 🎼
  В нотах всё аккуратно записано: сверху вниз, слева направо. Но музыкант, читая ноты, должен сначала понять тональность, размер, темп, и только потом играть каждую ноту по порядку. То есть фактически исполняется не в том же порядке, как просто «прочитал глазами».

• Рецепты в кулинарии 👩‍🍳
  В рецепте шаги написаны линейно: 1, 2, 3. Но когда готовишь, иногда сначала ставишь воду кипятиться, пока режешь овощи. Т.е. порядок написанного ≠ фактический порядок действий.

• Юридические документы 📑
  Контракт читается сверху вниз, но при толковании юристы сначала смотрят на определения терминов, потом на условия, потом на исключения.

• Программирование в целом 💻
  В коде написано: «вызови функцию А, потом Б». Но компилятор или интерпретатор сначала обрабатывает импорт библиотек, парсит синтаксис, оптимизирует, и только потом «доходит» до исполнения.

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

И для формирования таблиц в БД есть свои требования, нюансы и особенности.

Очень часто аналитики сталкиваются со следующими проблемами при работе с данными:

Слишком много столбцов

Иногда пытаются «запихнуть всё» в одну таблицу. Получается «широкая простыня» с сотнями колонок.
Такой подход приводит к тому, что становится неудобно работать, запросы тормозят, а половина столбцов вообще пустая.

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

Грубо говоря, нормализация - это способ организации данных. Что именно хранится, где именно хранится и как все, что хранится, связано между собой.

Дублирование данных

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

Это приводит к сложности обновления — изменил телефон в одном месте, а в другом он остался старым; объем БД растет, что требует увеличения ресурсов для работы с данными.

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

И это тоже про нормализацию данных.

Пустые ячейки (NULL)

Есть поле, но оно ничем не заполнено. И тогда аналитик задается вопросом: что это значит? Что данных просто нет (их никто не вносит), данные вносят, но они потерялись при загрузке в таблицу, либо эти данные необходимо воспринимать как равные нулю...

В этом случае необходимо сначала посмотреть требования к источнику данных, есть ли там обязательность их заполнения. Если данные обязательны к заполнению, то стоит рассмотреть ETL (Extract Transform Load - извлечение, преобразование и загрузка) процесс данных.

И от полученных результатов принимать решение как расценивать NULL данные.

Неправильный тип данных

Телефон хранят как INT, даты — как текст, деньги — как FLOAT.
Такой подход приводит к тому, что в телефоне «съедается» +7, даты не сортируются, а деньги теряют копейки.

И аналитик не может корректно обрабатывать данные, что приводит либо к ошибкам в результатах, либо к увеличению этапа обработки данных для выполнения какой-либо аналитики.

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

Нет ключей и индексов

Ключи нам нужны, чтобы однозначно идентифицировать данные и связывать таблицы между собой.

Есть первичный ключ (Primary Key) и внешний ключ (Foreign Key)
Первичный ключ - это уникальный идентификатор. Например есть два Ивановых Ивана Ивановича, но у них будут разные ID. Этот ID будет однозначно идентифицировать каждого из них.
Внешний ключ - это ссылка на другую таблицу. Например есть таблица заказов и в ней есть поле client_id. Это поле будет ссылаться на ID нашего Иванова Ивана Ивановича в таблице с персональными данными.

Индексы нам нужны для ускорения поиска.

Представь, у тебя есть огромная книга (миллионы строк в таблице). Если ты ищешь слово вручную — придётся листать страницу за страницей.

Но если есть алфавитный указатель (индекс) — ты сразу находишь нужное слово.

Примеры:

• Поиск клиента по номеру телефона

• Поиск заказов по дате

• Поиск товаров по категории

Индексы ускоряют запросы в разы, но требуют памяти и времени на обновление (поэтому ими злоупотреблять тоже не стоит).

Слияние «всего подряд»

Если таблицу использовать как свалку — складывать туда и клиентов, и товары, и заказы — это как в одной кастрюле сварить борщ, компот и макароны.
Итог: никто не понимает, что с этим есть.

А в канале На связи: SQL уже первые посты про структуры запросов и JOIN ждут тебя.

Если тебе нужна поддержка и мотивация или просто сопутствующие слова для твоего развития, то приходи в канала Сила слов. Там каждое утро тебя ждет мотивационное и поддерживающее послание.