Обновите вложенную таблицу 3-го уровня, чтобы добавить запись

Следуя примерам, найденным здесь, на https://cloud.google.com/bigquery/sql-reference/dml-syntax, мы придумали способ обновить 3-й уровень таблицы (спецификации. размеры) как таковой:

UPDATE sd97dwo.DetailedInventory
SET specifications.dimensions = 
    STRUCT<depth FLOAT64, height FLOAT64, width FLOAT64>(1, 2, 3)
WHERE 
    product like '%washer%'
    AND EXISTS(select 1 from unnest(comments) as c where c.comment like '%comment%')

Что мы сейчас пытаемся сделать, так это обновить таблицу, чтобы ДОБАВИТЬ запись в ту же самую структуру измерений. Однако разные способы, которые мы пытаемся, не увенчались успехом. Хотел посмотреть, есть ли у кого-нибудь идеи. Самым близким из полученных нами результатов был приведенный ниже, но он, конечно, возвращает все записи (в виде нескольких результатов) для спецификаций. Размеры, поэтому мы получаем ошибку «Скалярный подзапрос создал более одного элемента»

UPDATE sd97dwo.DetailedInventory
SET specifications.dimensions
    = (SELECT specifications.dimensions
    UNION ALL
    SELECT STRUCT<depth FLOAT64, height FLOAT64, width FLOAT64>(4.0,5.0,6.0))
WHERE 
    product like '%washer%'
    AND EXISTS(select 1 from unnest(comments) as c where c.comment like '%comment%')

google-bigquery gcp
person chillerm    schedule 30.09.2016    source источник
comment
Другое, но может быть связано, как вы преодолели жесткое ограничение в 48 максимальных операторов UPDATE / DELETE в день для каждой таблицы? Или попробовать с этим разобраться? cloud.google.com/bigquery/sql-reference/   -  person Pentium10    schedule 30.09.2016
comment
Наше общее мнение таково, что к тому времени, когда мы действительно дойдем до этого уровня обновлений, Google будет готов увеличить квоты, как и в случае с большинством других вещей. Однако до тех пор, пока закулисная работа создает совершенно новую таблицу с обновленными полями, мы будем избегать интенсивного использования из-за затрат / времени. Я просто пытаюсь доказать преимущества / недостатки и разобраться в синтаксисе. Кроме того, обратите внимание, что это операции обновления, а не обновления полей, поэтому, если вы можете уйти с обновлением большинства ваших записей за один проход (с использованием объединений или ж / д), вам может не понадобиться все это для каждой таблицы.   -  person chillerm    schedule 30.09.2016
comment
Меня беспокоит, что это все еще не подходит, поскольку ограничение запроса составляет 256 КБ, что немного, если вы хотите поместить значения в операторы. Также, если вы помещаете измененные значения в таблицу и выполняете обновление с объединением из этой таблицы, это довольно сложно и ограничивает использование. Я вижу только опасения.   -  person Pentium10    schedule 30.09.2016

Ответы (1)


arrow_upward
3
arrow_downward

Что мы сейчас пытаемся сделать, так это обновить таблицу, чтобы ДОБАВИТЬ запись в ту же самую структуру измерений.

Какая у вас схема? Если вы используете ту же схему, что и в документации DML, то ни «спецификации», ни «размеры» не являются повторяющимися полями. Таким образом, вы не можете добавить к нему. Но вы можете обновить их напрямую, например:

UPDATE sd97dwo.DetailedInventory
SET specifications.dimensions.depth = 1,
     specifications.dimensions.height = 2,
     specifications.dimensions.width = 3
WHERE 
    product like '%washer%'
    AND EXISTS(select 1 from unnest(comments) as c where c.comment like '%comment%')
person Alex227    schedule 30.09.2016
comment
почему бы просто не SET specifications.dimensions = STRUCT<depth FLOAT64, height FLOAT64, width FLOAT64>(1, 2, 3), как в первой части вопроса? есть ли польза от вызова каждого элемента отдельно ?! - person Mikhail Berlyant; 30.09.2016
comment
Спасибо за ответ Алекс. Я использую структуры из документации, как вы упомянули, и на самом деле просто пытался думать о разных вещах, которые я, возможно, захочу сделать в будущем. Более конкретный вариант использования - реализация медленно меняющихся измерений в транзакции продажи. Мы хотим включить в транзакцию исторические подробности о skus. У нас была бы схема, подобная этой: {TRANS_KEY, {[TRANS_LINE, SKU, SLS, {[SKU_CLASS, SKU_DEPT, EFF_DT]}]}} Если элемент меняет класс / отдел, я хочу добавить запись в существующий TRANS_KEY / TRANS_LINE, который показывает старый {CLASS / DEPT / DT} и новый. - person chillerm; 30.09.2016
comment
Закончились символы, поэтому дайте мне знать, если вам нужно больше ясности. Чтобы запустить обновление, я бы присоединился к таблице SKU, которая содержит новые детали для skus. - person chillerm; 30.09.2016
comment
После указания схемы я могу добавить в свою третью вложенную структуру после изменения их на повторяющиеся поля. Это делает то, что я задумал: UPDATE temp.DetailedInventory SET спецификации = ARRAY (SELECT AS STRUCT s.color, s.warranty, ARRAY_CONCAT (s.dimensions, ARRAY ‹STRUCT‹ глубина FLOAT64, высота FLOAT64, ширина FLOAT64 ›› [(9.0, 9.0, 9.0), (5.0, 5.0, 5.0)]) КАК размеры ОТ UNNEST (спецификации) КАК s) ГДЕ продукт как '% washer%' - person chillerm; 01.10.2016