← Все курсы · Курс SQL

СЛУЧАЙ, КОГДА с перекрывающимися условиями в SQL

Майкл Носито · Обновлено в августе 2026 г. · Каждый запрос на этой странице был выполнен до его публикации.

На этой странице представлен двухстрочный тест, который показывает, CASE Выражение означает тихое решение чего-то от вашего имени. Это важно, поскольку перекрывающиеся условия не приводят к ошибкам и двойному учету. Они выбирают один ответ, и ответом будет та строка, которую вы написали первой. У десяти клиентов ниже перемещение одной строки изменило количество VIP с 2 до 4.

Что вы делаете: записываете по одному столбцу флагов для каждого правила, затем подсчитываете строки, в которых два флага равны 1. Это те строки, для которых ваша помеченная версия должна была выбрать. Если это число не равно нулю, порядок вашего WHEN линии — это бизнес-решение, и кто-то должен был принять его намеренно.

Краткая версия. CASE останавливается при первом истинном условии. Поэтому, когда два условия могут быть истинными, порядок является логикой.

Таблица, на которой выполняются примеры

Десять клиентов, три столбца, которые имеют значение: сколько они потратили, когда зарегистрировались и когда последний раз заказывали. Для каждого расчета на этой странице сегодня 23 августа 2026 года.

CREATE TABLE customers(name TEXT, spend INT, signed_on TEXT, last_order TEXT);

INSERT INTO customers VALUES
('Alvarez',1400,'2026-08-14','2026-08-20'),
('Brennan',1250,'2025-02-03','2026-08-18'),
('Cho',      90,'2026-08-09','2026-08-09'),
('Diaz',    620,'2025-11-20','2026-03-02'),
('Ellis',  2100,'2024-06-01','2026-02-11'),
('Fowler',  310,'2026-08-01','2026-08-16'),
('Grant',   180,'2025-09-14','2026-04-30'),
('Hale',   1050,'2026-08-20','2026-08-21'),
('Iyer',    460,'2025-05-05','2026-08-12'),
('Jansen',  NULL,'2025-07-07','2026-01-15');

Правила трех сегментов, о которых просит любая маркетинговая команда. Новые средства, зарегистрированные за последние 30 дней. VIP означает расходы в размере 1000 или более. Под риском подразумевается отсутствие заказов в течение более чем 90 дней. Каждый из них разумен сам по себе.

Два правила, один клиент и никакой ошибки

Перед вопросом: Хейл зарегистрировался 20 августа и потратил 1050. Какому из трёх правил соответствует Хейл?

Двое из них. Хейл новенький и Хейл VIP. Ничто в SQL не возражает против этого, потому что CASE не сверяет ваши правила друг с другом. Он ходит по WHEN строки сверху, берет первую истинную и останавливается.

SELECT name, spend,
       CASE WHEN julianday('2026-08-23') - julianday(signed_on) <= 30 THEN 'new'
            WHEN spend >= 1000                                       THEN 'vip'
            WHEN julianday('2026-08-23') - julianday(last_order) > 90 THEN 'at risk'
            ELSE 'active'
       END AS segment
FROM customers;

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

Два условия, оба из которых могут быть истинными для одной строки, называются перекрытием. Два условия, которые не могут быть названы взаимоисключающими. Группы, построенные из одного столбца, например, менее 500, 500 или более, являются взаимоисключающими, и их порядок на самом деле не имеет значения. Правила, построенные на основе разных столбцов, почти всегда перекрываются.

Переместите одну строку, и количество VIP увеличится вдвое.

Во-первых: если VIP-правило переместится наверх, сколько из десяти клиентов поменяют сегмент?

Двое из них, Альварес и Хейл, и этого достаточно, чтобы изменить каждое число, которое читает заинтересованная сторона. Здесь учтены оба заказа, одни и те же данные, те же три правила.

Оба раза общая сумма равна 10, и именно поэтому это выдерживает проверку. Ничего не пропало, ничего не дублируется, и сумма согласуется. Проверка сверки вообще не может выявить эту проблему, поскольку оба ответа внутренне непротиворечивы. Только раскол сдвинулся.

Прежде чем читать дальше, произнесите это вслух: если количество VIP удвоилось, а общее количество не изменилось, откуда взялись два дополнительных VIP? Они пришли из нового сегмента и всегда были и тем, и другим.

Заказчик обе версии скрывают

Прежде чем ответить: Эллис потратил 2100 и последний раз заказывал 11 февраля, более шести месяцев назад. Как зовут Эллиса?

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

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

SELECT name,
       CASE WHEN julianday('2026-08-23') - julianday(signed_on) <= 30 THEN 1 ELSE 0 END AS is_new,
       CASE WHEN spend >= 1000                                        THEN 1 ELSE 0 END AS is_vip,
       CASE WHEN julianday('2026-08-23') - julianday(last_order) > 90 THEN 1 ELSE 0 END AS is_at_risk
FROM customers;

В трёх рядах по две единицы: Альварес, Эллис и Хейл. Это те три строки, которые должен был выбрать помеченный запрос, и теперь вы можете видеть их, а не гадать. Эллис, заядлый транжира, находится на расстоянии одной строки SQL: WHERE is_vip = 1 AND is_at_risk = 1.

Флаги тоже честно складываются. Четыре клиента по правилу являются VIP-персонами, какой бы порядок вы ни использовали. На этикетке было указано 2 в одной версии и 4 в другой, потому что метка — это рейтинг ваших правил, а не показатель количества ваших клиентов.

Ветка, которая никогда не сможет работать

Во-первых: какая из этих двух меток никогда не появится в выводе?

SELECT name, spend,
       CASE WHEN spend >= 100 THEN 'over 100'
            WHEN spend >= 500 THEN 'over 500'
            ELSE 'small'
       END AS band
FROM customers;

over 500, и запрос выполняется чисто. Каждый клиент старше 500 человек также старше 100, поэтому первая линия занимает их всех. Восемь строк возвращаются как over 100, два как small, и over 500 это ноль строк. Метка существует в SQL и ни разу не попадает на экран.

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

SELECT segment, COUNT(*) AS rows_labelled
FROM (SELECT ..., CASE ... END AS segment FROM customers)
GROUP BY segment
ORDER BY rows_labelled;

Как протестировать любой КЕЙС за две минуты

Три проверки, и ни одна из них не требует инструмента, которого у вас еще нет.

1. Подсчитайте количество строк на этикетке. Ноль означает недоступную ветвь или правило, которому никто не соответствует. Этикетка, содержащая почти все, обычно означает, что состояние более слабое, чем предполагалось.
2. Перепишите правила в виде флагов и посчитайте перекрытия. SELECT COUNT(*) FROM (...) WHERE is_new + is_vip + is_at_risk > 1 возвращает 3 в этой таблице. Все, что выше нуля, означает порядок вашего WHEN линии решают результаты.
3. Переместите строки и повторите попытку. Если показания изменятся, у вас есть доказательства. Если это не так, ваши условия являются взаимоисключающими, и вы можете не беспокоиться о порядке в этом запросе.

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

/* WHY: Priority order is deliberate. A customer who is both new and a VIP is
   counted as new, because the onboarding campaign owns them for 30 days.
   3 of 10 customers meet more than one rule, so this order is the decision. */

Представьте себе последнюю сегментацию, которую вы отправили. Два ее правила рядом: может ли один клиент соответствовать обоим? Если вы не можете ответить на этот вопрос по памяти, это запрос, который нужно запустить завтра для проверки флага.

Пограничные случаи, которые стоит знать

NULL никогда ничему не соответствует, поэтому он попадает в ELSE. У Янсена не зарегистрировано никаких расходов. В примере с группой NULL >= 100 не является ни истинным, ни ложным, поэтому Янсен проваливается до small, что читается как «тратит очень мало» и на самом деле означает «мы не знаем». Дайте неизвестным свою ветку: WHEN spend IS NULL THEN 'unknown', во-первых, перед чем-либо, что проверяет столбец. Подробнее об этом поведении см. NULL в SQL.

Нет ELSE Означает NULL, молча. A CASE условия, для которых закончились условия, возвращаются NULL для этого ряда, а не поднимать что-либо. Затем GROUP BY дает вам пустой сегмент в отчете. Всегда пишите ELSE, даже если вы считаете, что он недоступен, и поместите в него что-нибудь читабельное, например 'unclassified'.

BETWEEN полосы перекрываются по шву. BETWEEN 0 AND 10 и BETWEEN 10 AND 20 оба содержат 10. В CASE это не двойной счет, а просто спокойно передает 10 первой группе. Напишите группы с одним инклюзивным концом, например < 10 затем < 20, и шов перестает быть решением.

Обрезки, существующие в SQL, должны быть изменены в SQL. Если в следующем квартале порог VIP достигнет 1200, каждый запрос, содержащий это число, необходимо будет найти. Если более двух или трех запросов используют один и тот же набор правил, поместите полосы в небольшую таблицу и вместо этого присоединитесь к ней.

Правило первого совпадения является стандартным, а не особенностью движка. PostgreSQL, MySQL, SQL Server, SQLite и Оракул оценивают WHEN предложения по порядку и остановитесь на первом верном. Переписываю то же самое CASE на другом двигателе то, что он делает, не изменится.

Почему это работает таким образом

CASE это не набор взвешиваемых правил. Это цепочка операторов если, и возвращается первый истинный оператор.

Этот дизайн продуман, и именно это делает CASE безопасно использовать для защиты от ошибок. Поскольку оценка останавливается на первой истинной ветви, вы можете написать WHEN denominator = 0 THEN NULL WHEN ... THEN total / denominator и деление никогда не заканчивается на нуле. Если SQL оценит каждую ветвь, а затем выберет ее, этот шаблон потерпит неудачу.

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

Как применить это в своей работе

1. Откройте CASE вы используете больше всего. Для каждой пары условий спросите, может ли одна строка удовлетворять обоим.
2. Если какая-либо пара может это сделать, перепишите правила в виде столбцов флагов один раз и подсчитайте строки с более чем одним установленным флагом.
3. Решайте, какой факт победит, вместе с человеком, которому принадлежит эта метрика, а не один за вашим столом.
4. Напишите это решение в комментарии над CASE, называя приоритет и причину.
5. Сохраните версию с флагом. Метки предназначены для отчетов, флаги — для вопросов, а запрос с флагами — там, где находятся интересные строки.
6. Не проводите модернизацию каждый CASE в кодовой базе на этой неделе. Начните с тех, чьи номера публикуются.

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

Шпаргалка

Единственная привычка, которую нужно сохранить

Прежде чем написать CASE, возьмите любые два его условия и спросите, может ли одна строка удовлетворять обоим. Если ответ положительный, вы не пишете классификацию. Вы пишете список приоритетов, а списки приоритетов принадлежат бизнесу, а не тому, кто напечатал запрос.

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