Насчёт минуса согласен. И как раз столкнулся с тем что нужно скорректировать механизм расчёта...

То есть предрасчёт будет работать быстрее в визуализации только если очень много данных. И прироста производительности на  мы не получим. Правильно понял?

Ну там основных команд там штук 10

Ну если
SELECT * FROM ANYTABLE то 4...
Если добавить WHERE то 5

Как на счет типов блокировок? merge join или  nested loop join? Знание алфавита не равно знанию языка.

Думаю  даже CTE и курсоры за 2 дня освоить сложновато будет.

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

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

Когда речь идёт о предрасчёте выручки/чеков за день, тут согласен. Скорее надо чем не надо... Делаем предрасчёт и работаем с этими данными.
А тут получается те же сводные данные, только с другого периода.
Пытаюсь понять мотивацию реализации такого решения.

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

Ну + 2 дня)

Алекс, не усложняй)

Был в самолёте, много пропустил,  вижу - еле теплится уголёк.
Подсыпаем дров: теперь все перечисленные для PowerBI языки попробуем привить  пользователю для его работы в режиме самообслуживания. Хотя бы для несложных задач. Не слабо? )))
И кстати, в PowerBI on-premise нет  интеграции с Python ))). И даже отношения m:n не понимает. Продолжать нужно?

Ну по поводу языков и режима самообслуживания это вы передергиваете...
А вот отсутствие функционала в on-premise это да... пичалька...

А что я передергиваю?
Даже если не вдаваться в детали, а просто считать перечисленные для PowerBI языки:
M, DAX, Python,  VisualBasic, SQL. Итого: 5 Все эти языки непохожи друг на друга.

Считаем для Qlik:
язык функций (язык в скрипте и в объектах визуализации можно считать за один, т.к. на 90% обладает едиными синтаксическими конструкциями)

SQL. Итого: 2

И то, в принципе, если не заниматься оптимизацией, то и без SQL можно в Qlik обойтись )))

А как насчёт того, чтобы пользователю человеческим языком объяснить, почему в DAX есть 4 варианта суммирования?
А как насчет 4 типов фильтрации, настройка которых из-за одностороннести связей вынуждает заниматься программированием на элементарных вещах?
А как насчёт жутких формул с названиями таблиц, от которыхне отказаться?
А как насчет ручного создания справочников для ключевых полей (я уже не говорю про составные ключи)?

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