Если единственной причиной, по которой вы не используете UNNEST , является непроверенный результат, я бы не стал отказываться от этой опции. Хотя я бы посоветовал вам использовать UNNEST и не выбирать неопубликованные столбцы. Таким образом, сохраняя вложенный результат, вы сможете использовать эти новые временные столбцы для проверки ваших условий в ваших CASE WHEN заявлениях.
Я использовал publi c набор данных в BigQuery, чтобы проиллюстрировать этот алгоритм для вас. Синтаксис:
WITH
temporary_table AS(
SELECT
*,
param
FROM
`firebase-public-project.analytics_153293282.events_20181003`,
UNNEST(event_params) AS param )
SELECT
*,
CASE
WHEN (param.key IN ('value', 'board')) THEN TRUE
END
AS check
FROM
temporary_table
LIMIT
100;
Обратите внимание, что unnested столбцы из event_param не отображаются в конечном результате. Кроме того, столбец check был создан и использован как логическое значение, которое может быть опущено, а также может использоваться как флаг для внесения желаемых изменений в желаемые столбцы.
Надеюсь, это поможет.