Вложенный запрос (DAX2012)

[DesparioN]

Добрый день!

Продолжая эпопею с оптимизацией запросов, появилась потребность в получении значения не перебором, а единым запросом.

Необходимо сделать следующее:
1) сгруппировать таблицу по 2 полям
2) посчитать максимальное значение по полю 2, сгруппировав по полю 1

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

Возможно ли сделать подобный запрос в Аксапте?

[mazzy]

Цитата:

Сообщение от DesparioN

Возможно ли сделать подобный запрос в Аксапте?

да, чёрным запросом
https://github.com/mazzy-ax/SysResultSet

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

но вопрос скорее надо ставить не "возможно ли?",
а "какое решение экономически целесообразно"?
с точки зрения поддержки, с точки зрения модифицируемости и дальнейшего развития системы.

например, стопудов ваши два пункта не последние, а часть какого-то большого алгоритма. в этом большом алгоритме наверняка определяются и входящие условия, и как будут использоваться результаты этого запроса. стопудов выяснится, что в алгоритме используется еще и "поле 3", "поле 4" и "поле N", из-за которых вам придется делать дополнительные выборки.

[fed]

В DAX2012 (и даже в Dax2009) можно создать view.
Сначала создаем View с двумя полями, основанный на Query, в котором по этим двум полям группировка.
Потом пишем запрос

 while select maxof(field2),Field1
From MyView
Group by field1
{
}

[sukhanchik]

Небольшие 5 копеек.
Если табличка большая по объёму (несколько миллионов записей), то будет критично, если по полям, перечисленным в условиях отбора (WHERE), условиях группировки (GROUP BY) и условиях сортировки (ORDER BY) нету хотя бы частично покрывающего (по полям, содержащие наиболее уникальные значения, можно не по всем полям) индекса.
Поэтому в идеале - все типы запросов к таблице нужно свести к ограниченному количеству и по ним построить рекомендуемые базой данных индексы.

Собственно поэтому количество полей в GROUP BY лучше зафиксировать и не расширять (т.е. если потребуется расширение - решать эту задачу не одним запросом, а несколькими)
Совет актуален в первую очередь для периодической выборки.

[dech]

Добрый день. Для меня немного непонятно, почему нельзя опустить пункт 1?
Зачем сначала делать группировку по 2 полям, чтобы потом получить максимальное с группировкой - и всё это на базе тех же самых 2 полей?
Есть какой-то скрытый смысл?

[DesparioN]

Да, будет разное количество. Условно на каждую пару полей приходится по 20-30 строк. Т.е. без второго пункта будет не 2 записи, 40-60.

[DesparioN]

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

[mazzy]

Цитата:

Сообщение от DesparioN

Да, будет разное количество.

Цитата:

Сообщение от DesparioN

программируемых полей

как всегда в программистских задачах:

помните, что группировка по полю без индекса - это Table scan.
т.е. вам нужно подумать не как запрограммировать в Аксапте универсальный запрос.
а о том, как сделать ваш код в целом быстрым и эффективным. возможно, стоит даже не ограничиться только SQL, а по-другому распределить нагрузку между SQL и AOS.

уверяю вас, "универсальные запросы по произвольным полям" - это зло.

лучше переделайте вашу схему данных.

[dech]

Цитата:

Сообщение от DesparioN

Да, будет разное количество. Условно на каждую пару полей приходится по 20-30 строк. Т.е. без второго пункта будет не 2 записи, 40-60.

Вы меня не совсем правильно поняли, Что будет результатом без первого пункта?
Или может быть я вас не совсем так понял? Давайте разберем пример.
Допустим, вы хотите узнать время последней активности по всем клиентам и группируете CustTrans по полям AccountNum(1) и TransDate(2).

Пункт 1. Вы делаете группировку по AccountNum, TransDate
Пункт 2. Вы также делаете группировку по AccountNum, а по TransDate ищете максимальную дату.
Разве изменится что-то, если вы выкинете пункт 1 и оставите пункт 2?

[DesparioN]

Условие другое: требуется найти не максимальную дату, а максимальное количество разных дат.

[DesparioN]

Еще помучаю, если можно. Написал запрос.
В итоге, если:
1) взять COUNT(Field) order by Field DESC, то получается 2.
2) Если перебором, то получается 3
3) если в п.1 добавить фильтр по номенклатуре e которой реально 3, то получается 3.

С чем это может быть связано?

Для справки, если это может быть важно, Field - string

[fed]

Цитата:

Сообщение от DesparioN

Еще помучаю, если можно. Написал запрос.
В итоге, если:
1) взять COUNT(Field) order by Field DESC, то получается 2.
2) Если перебором, то получается 3
3) если в п.1 добавить фильтр по номенклатуре e которой реально 3, то получается 3.

Все таки уточню задачу. Я так понимаю, у вас есть что-то типа таблицы товародвижений. Первое поле - некое ключевое поле (типа клиента или номенклатуры), второе поле - что-то считающееся транзакционным - может быть дата, может быть код номенклатуры (если первое поле - код клиента). Задача состоит в том чтобы для каждого значения первого (ключевого) поля, вывести число уникальных значений второго (транзакционного) поля. (типа - сколько раз грузили клиенту, или сколько разных номенклатур покупал клиент).
В таком случае, задача решается так:
1. Создается view1 по основной таблице, во вьюшке оба поля, по обоим полям стоит группировка.
2. Создается view2. View2 построено по view1, сделана группировка по ключевому полю (field1), поставлена функция count(recid) (второе поле тут строго говоря вообще не при делах, сount нужно делать по любому int64 полю, recId -наиболее очевидный кандидат).

Во view2 в итоге будут находится записи в которых для каждого значения ключевого поля во втором поле будет находится число уникальных значений транзакционного поля в оригинальной таблице.

[dech]

Цитата:

Сообщение от DesparioN

Еще помучаю, если можно. Написал запрос.
В итоге, если:
1) взять COUNT(Field) order by Field DESC, то получается 2.
2) Если перебором, то получается 3
3) если в п.1 добавить фильтр по номенклатуре e которой реально 3, то получается 3.

С чем это может быть связано?

Для справки, если это может быть важно, Field - string

Сортировка по агрегированному полю, а также отсутствующему в группировке не срабатывает.
Возможно стоит попробовать выполнение запроса на чистом SQL, без создания дополнительных вьюшек.
В этом случае можно воспользоваться ORDER BY N, где N - это номер поля, участвующего в выборке.
Note! Класс с вашим запросом должен исполняться на сервере.

[S.Kuskov]

Цитата:

Сообщение от DesparioN

1) взять COUNT(Field) order by Field DESC, то получается 2.

Вы наверное ожидаете что order by будет применён к результату агрегирующей функции? В Аксапте оно так не работает. Только если, как вам уже советовали, явно зафиксировать результат агрегации в виде View, а потом уже внешним по отношению к View запросом отсортировать результат

[DesparioN]

Понял, принял. Благодарю.

[Владимир Максимов]

Странно, что решение "в лоб" не рассматривается

1. Выборка с группировкой во временную таблицу
2. Выборка по временной таблице из п.1

View - это большие "накладные расходы" на сопровождение. Иногда нужно, конечно, но лучше обойтись

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Странно, что решение "в лоб" не рассматривается

так задал вопрос топикстартер:

Цитата:

Сообщение от DesparioN

появилась потребность в получении значения не перебором, а единым запросом.
...
Возможно ли сделать подобный запрос в Аксапте?

[Владимир Максимов]

Так это решение и есть. Не перебором. Отличие только в том, что не один запрос, а два