Oleg , интересно какой подход можете посоветовать для построения ABC/XYZ анализа на большом количестве записей? При вычислениях на стороне виза через aggr минут 5-10 уходит на расчет одной таблицы... А хочется использовать ABC так чтобы он зависел от фильтров

Вычисления на стороне визуала хороши своей гибкостью. Но цена - это производительность, да. Мы для гибкого ABC-анализа с большим кол-вом данных используем несколько предпосчитанных сценариев на стороне скрпита, а в визуале используем всякие переключалки для подмены измерений/вариантов.

В 99% случаев оказывалось что абослютная гибкость - это блажь, и аналитика проходит по нескольким фиксированным сценариям

Это интересный вопрос... AGGR как известно очень тяжёлый на большом количестве данных, поэтому меня не удивляет что это занимает 5-10 минут. В зависимости от конкретных требований, можно попробовать использовать расширенный поиск в Сет Анализе. Иногда можно обойтись малой кровью. Иногда приходится сказать заказчику "Нет". Как поется в песне, "You can't always get what you want"

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

А большой объем данных это сколько?

Чтобы это посчитать в скрипте, нужно аггрегировать по всем параметрам, которые доступны для выборки - то есть, практически возвращаться к нудному процессу построения многомерного ХД. Очень неприятно, но иногда необходимо.

По моим понятиям, свыше 10 миллионов записей - уже нужно обращать особое внимание на производительность. С точки зрения AGGR - свыше 1 миллиона уникальных значений измерения - это уже многовато. Нужно искать другие решения.

Также, можно освоить динамическое формирование скрипта и написание подпрограмм (sub). Поможет автоматизировать много рутинных операций

Прошу прощения. Я скорее имел ввиду, что это возможно только в случае жёстко установленных критериев присвоения рейтинга A, B или С. Т.е. к примеру: за год по выручке в разрезе клиентов или категорий или по прибыли и т.д. И любой выход за эти рамки немного лишает смысла рассчитанный заранее рейтинг. Например: за два года, только один бренд, в одном регионе.. вариаций множество..

Имеется ввиду установка каких-либо отборов/критериев и последующая загрузка данных и предрасчетов с учётом этих отборов?

ну, типа того

Теоретически можно, но мне кажется что если объем данных уже достаточно большой то в принципе перезгрузка данных может занять больше времени чем расчеты в диаграммах. Хотя, конечно, такой способ имеет право на существование)

Сейчас, ради любопытства посмотрю свой объем данных

нужно продумывать пользовательский ценарий полностью. Начиная с определенного объема, свалить все на визуалку не выйдет. Особенно когда несколько пользователей работают с приложением. Уверен, что сценариев для анализа у вас конечное число, и их менее 10)

Для ускорения загрузки, можно задействовать функционал ODAG - он позволяет сделать загрузку данные в приложение по запросу пользователя с ограничениями на основе выборок в другом приложении

Всем привет! У меня тут проблема с синтетическим ключом...
Есть предшествующий LOAD без FROM - в нем идут вычисления дополнительных полей, потом идёт цикл, который запускает несколько SELECT'ов. Первый селект успешно заливается в первый LOAD таблицу, все оставленные льются в новую,  без нужных мне вычислений и создаётся синтетический ключ аро всем полям... если я убираю дополнительные вычисления в первом LOAD, то на выходе таблица одна. Это как то лечится?

Вам нужно таблицы соединить "по-вертикали" ? CONCATENATE

Посмотрите concatenate и noconcatenate