Их и смотрю, но в виде курса пока толкового не нашел. Купил 1 курс на udemy.

Очень трудно соревноваться толковым курсам с теми, так сказать, курсами, которые индусы выкладывают за $29...

Московский курс Олега Троянского завершился, а значит, самое время напомнить о нашем ноябрьском тренинге: qRUG Camp 2019, 14-15 ноября.
Осталось 10 дней до повышения цены - успейте зарегистрироваться!

Кратко о Qlik-тренинге qRUG Camp 2019:

- Тренинг проводится уже 6-ой раз, каждый год с новыми темами и фишками, собирает порядка 100 разработчиков и аналитиков Qlik
- qRUG Camp нацелен на тех, кто активно вовлечен в разработку и дизайн приложений Qlik - архитекторы, разработчики, аналитики BI
- Все материалы, презентации, qvw и qvf файлы выдаются всем участникам после тренинга - можно спокойно разобраться и реализовать в компании
- Ключевые темы этого года - «Продвинутое моделирование и вычисления с Qlik», «Нагрузочное тестирование приложений», «Практика и методика построения сложных форм финансовой отчетности»,  «Использование Python-а для подготовки данных в Qlik», «Возможности визуализации, с примерами и кейсами» и т.д.
- На Параде Tips&Tricks будет 20+ фишек по работе с QlikView и Qlik Sense. Полная программа тут: http://qrug.me/program/

Отличная программа!

Олег, спасибо 😊

Так точно. Недостатков у Direct Discovery больше, чем достоинств. Он развиваться не будет. Такой ограниченный функционал работы с данными - удел других инструментов.

Не совсем так. Direct Discovery обеспечивает прямой запрос из таблиц данных. Т.е. так, как это делают все инструменты других производителей.
ABDI - это работа с ассоциативно связанным множеством данных состоящим из любого количества таблиц. По сути ABDI - новая версия движка Qlik, предназначенная для интерактивной ассоциациативной работы с большими объёмами данных (десятки млрд. записей)

Я бы согласился с обоими суждениями. Технически это два разных решения, но с точки зрения пользователя, они призваны решать похожие задачи - как анализировать громадные объемы данных, которые невозможно загрузить в память целиком. DD провалился, а ABDI пока ещё многообещающий.

Единственная фишка DD, ради которой про него стоит помнить - возможность показывать обновленные записи источника без перезагрузки скрипта. Но реалтайм-мониторинг - это не прерогатива BI систем) И DD имеет ряд неприятных ограничений. Например на данных полученных через ДД нельзя применить Set-Analysis. Каждое обновление визуализации=новый запрос к источнику, что может создать нежелательную нагрузку.

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

У direct discovery самая частая причина использования в том что некоторые заказчики упорно полагают что реляционная субд которая им нравится (Postgres/Oracle/  итд) быстрее Qlik на агрегациях 🙈

Если рассматривать агрегацию в чистом виде - так оно и есть

"В чистом виде" это SELECT SUM(Поле) FROM Таблица ?

Security Rule, который показывает закладки со словом SHARE в названии, созданные одним пользователем, всем другим пользователям

Всем привет, забуксовал на ровном месте. Вывожу таблицу по сотрудникам. Считаю количество продаж. И нужно каждого сотрудника сравнить с медианой по сотрудникам не из selection. Какую формулу использовать? Первое что пришло в голову:
Sum({<FIO=E{FIO}>} TOTAL <FIO> Sales)
Но она логично выводит продажи по каждому сотруднику вне selection. А как положить их сумму в строчку с сотрудником из selection? Не соображу...

а зачем вам <FIO> после тотала?

для вашего примера оно не нужно

ну и сумму надо будет в aggr завернуть, а его в формулу медианы

типа median(total aggr(sum(поле),fio))

Ну чтобы добраться до медианы пытаюсь сумму сначала вывести