матчасть говорит другое)
P.S. вообще говоря, оператор OR в кликовском языке запросов редко используют)

XOR еще реже))

да, это реально редкие кейсы.,,

Для маленьких мер с ифами можно, аля суммесли(или(... в экселе. Но на маленький массив данных подойдёт, а так более важна грамотно построенная модель данных и связи логичные

)

По сути пришёл к тому, что в приложение ничего лишнего грузить не стоит, все возможные таблицы рассчитать в скрипте загрузки, а в визуализациях простые меры и измерения, несколько фильтров, kpi ну и справочную таблицу в зависимости от задачи если нужна, связанную по уникальному id. Фильтрами как правило не пользуются. Только если какое то территориальное деление есть, каждый будет выбирать свою территорию. Динамика на графиках

путь эволюции - спираль.
просто к вам еще не пришел тот искушенный маркетолог из какой-нть страховой, например, компании.😂

Неее, нам страховые не страшны) у нас по страшнее

А маркетолог тут уже больше я и есть😃

если ваш случай выше ("по сути пришел к тому...") описан точно, то никакой клик/пибиай/таблюауауа вам не нужен. Сгодится какой-нибудь Looker ибн Суперсет скрещенный с LDAP (пользователи домена). ))

Клик инструмент для визуализации, как и прочие bi, big data аналитика на уровне скрипта загрузки происходит. Обрабатывали миллиард строк, тупо чтобы визуализировать как есть - ресурсы колоссальные нужны

ок, тогда клик может спать спокойно))
клиент лоялен бренду))

Обрабатывали 20 млрд строк, вот это да, колоссальные ресурсы, клик никогда не был инструментом только визуализации, просто здесь все зависит от большого набора параметров и требований, и дизайн решения и архитектуры исходит исключительно от них. Просто так записать миллиард строк в любую систему и показывать как есть, так здесь не только клик, а что угодно не будет работать. Кроме того с миллиардом строк вообще никто не в состоянии работать, кроме как через уровни абстракции, то есть как минимум через визуализации и агрегации. Все всегда зависит от требований и конечного дизайна всего решения, вот так, а не иначе. Имхо.

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

Если Вам надо построить рекомендации по сопутствующим товарам по большому массиву данных, то похоже, нужен алгоритм Априори, как здесь предлагают: https://community.qlik.com/t5/Qlik-Sense-App-Development/Apriori-within-Qlik-Sense/td-p/1787503

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

Count(Distinct {<Остаток={">0"}>} [Артикул]) - before(Count(Distinct {<Остаток={">0"}>} [Артикул]))

Хотелось бы немножко оптимизировать и вынести эту логику в скрипт, но не понимаю как это сделать. Как можно посчитать count distinct в скрипте с учетом что в модели еще несколько измерений, кроме артикула и периода

Count(Distinct {<Остаток={">0"}>} [Артикул]) - before(Count(Distinct {<Остаток={">0"}>} [Артикул]))

В отдельной таблице и связать с основной по периоду?

Или фильтровать надо будет в том числе по доп.измерениям?

да хоть как

да основная проблема в том что нужно фильтровать по доп. измерениям