У меня есть столбец категории со строкой, содержащей поля подкатегорий в переменных положениях, разделенных символом «|». Расположение каждой подкатегории зависит от количества элементов в строке. Например:Условные сгенерированные сгенерированные транзакции Bigquery
category subcat1 subcat2 subcat3
a|b|c b c a
x|y|a|b b null a
Таким образом, чтобы решить для одной категории, у меня есть:
SELECT
a.category AS category,
case
WHEN COUNT(SPLIT(a.category, "|")) = 4 then nth(4, SPLIT(a.category, "|"))
WHEN COUNT(SPLIT(a.category, "|")) = 3 then nth(2, SPLIT(a.category, "|"))
WHEN COUNT(SPLIT(a.category, "|")) = 2 then nth(2, SPLIT(a.category, "|"))
else null
end as subcat1,
--nth(2, SPLIT(a.category, "|")) as x --uncomment for success. see below
FROM
[interim_groups.articles_unique] as a
Запуск этого терпит неудачу с:
SELECT clause has mix of aggregations 'subcat1' and fields 'category' without GROUP BY clause
Теперь я не хочу, пункт group by
и он не имеет смысла иметь его, но если я его включаю, он начинает жаловаться на скользящие скопления, которые, кажется, идут в неправильном направлении.
То же самое происходит, если я использую инструкцию if
вместо инструкции case
.
Теперь вот странный бит. Если у меня есть прокомментированная строка (или, альтернативно, last(SPLIT(a.category, "|")) as x
) в моем запросе, запрос проходит безупречно.
Это ошибка? Мой запрос выглядит правдоподобно, и наличие лишнего столбца в моем запросе каким-то образом делает его пропуск странным.
Есть ли лучший способ исправить это, чем просто оставить ненужный столбец для стабилизации запроса?
Отличное решение! Но см. Альтернативный ответ о том, как «WITHIN» исправляет проблему. –
полностью согласен! ВХОД - это путь сюда. Голосование за это! –
Мой запрос на самом деле начался с регулярного выражения, но регулярное выражение получило беспорядок, потому что не все строки между '|' были захвачены как целое слово (например, перенос) – Roman