Во вложенном архиве файл LeftJoinSQL.pbix. Запрос "PQJoin" возвращает таблицу, которую я хочу получить кодом на SQL внутри OleDb.DataSource. Запросом "SQLJoin (1 таблица)" я осилил соединение одной таблицы; А в запросе "SQLJoin (2 таблицы)" висит ошибка, которую я никак не могу понять. Попытки воспроизвести на SQL шаг с агрегированием, соответственно, не было
Предыстория: Запрос "PQJoin" до завершения шага с первым левым соединением на реальных данных (к 1,08кк строк тяну 42к) выполняется в два раза (!) быстрее, чем "SQLJoin (1 таблица)". Но на шаге #"Вычисленное значение Receipt" в рабочем файле запрос "PQJoin" умирает: за 4 часа не справляется (в таблицах в столбце 'Receipt' от 1 до 10 строк), дальше мне терпения не хватило ждать.
Прошу подсказать: 1) Что я сделал не так в коде SQL в "SQLJoin (2 таблицы)" и возможно ли это вообще? 2) Как будет выглядеть готовый код SQL, если после второго объединения еще добавить агрегирование (вернуть таблицу из шага #"Сгруппированные строки" в запросе "PQJoin"? 3) Есть ли менее ресурсоемкий, чем Table.AggregateTableColumn, способ в PQ развернуть с агрегированием присоединенные таблицы? При этом, применяемые функции PQ должны быть доступны в версии надстройки для Excel2013.
Есть. Table.Join + Table.Group. Ваш вариант это самый тормозной из всех что можно было придумать. Но, если к правой таблице применить функцию Table.AddKey, то тормозов станет значительно меньше. Погуглите эту функцию есть пара статей с примерами то ли у Криса Вебба, то ли у Кена Пульса, сейчас точно не помню уже.
Речь про два разных шага? Или про Table.Group() как аргумент Table.Join? Попробовал оба варианта: во втором ругается на повторяющиеся имена. Можете еще раз посмотреть пример?
Без разницы. Можно сделать как здесь предложил один хороший человек. А можно взять по той же ссылке постом ниже мой файл-пример и посмотреть как реализовано в нем.
genosser, только обратите внимание, что в тех примерах по ссылке опущен 5-й параметр, т.е. по умолчанию используется ИннерДжойн. Для вашей задачи, нужно будет прописать JoinKind.LeftOuter
PooHkrd, обратил внимание, спасибо. В примерах не совсем то, что я хотел, но то, что хотел, смог получить вот такой конструкцией:
Код
TGroup =
Table.Group(
Table.Join(
#"Развернутый элемент PC",
{"SKU", "PARID", "PARSTORE"},
Table.RenameColumns(
Receipt,
{{"SKU", "SKU1"},{"ID", "ID1"},{"STORE","STORE1"},{"QUA","PARQUA"}}
),
{"SKU1", "ID1", "STORE1"},
JoinKind.LeftOuter
),
{"SKU", "ID", "STORE","QUA"},
{{"PARQUA", each List.Sum([PARQUA]), type number}, {"COS1", each List.Sum([COS1]), type number}},
GroupKind.Local)
если честно, не ожидал, что получится, а теперь голова кипит.
Объясните, если не трудно, еще такие моменты: Конструкция выше будет ускорена, если к правой таблице ("Receipt") применить Table.AddKey(), или это применимо только в связке с Table.AggregateTableColumn()? Любую табличную функцию можно применить к любому объекту с типом table: неважно, является он шагом запроса либо вложенной таблицей в столбце? Код, например мой, начинает отрабатываться с наиболее глубоко вложенной табличной функции, в том числе, если аргументом другой табличной функции на нижнем уровне является #table ()? Т.е. сначала вычисляются аргументы #table(), потом на уровень вложения выше и т.д.?
genosser написал: Конструкция выше будет ускорена, если к правой таблице ("Receipt") применить Table.AddKey()
Фиг знает - надо тестировать.
Цитата
genosser написал: Любую табличную функцию можно применить к любому объекту с типом table
Да. Код выполняется условно говоря "в обратном порядке", это так называемые "ленивые вычисления" (lazy calculation). Т.е. сначала интерпретатор начиная с последнего шага выстраивает цепочку расчетов, которые нужно сделать, убирает все (по его мнению) "не нужные", и после этого уже начинает расчеты с начала выстроенной цепочки. С этим связано немало всяких интересностей, которые познаешь и учишься объезжать в процессе работы с этим чудным инструментом.