ну тут можно начинать от эксель файлов с 1 балом до БД в zure за 10 балов.

а так нормально обычный сиквел сервер

Ох, много написали, наверно при таких объемах надо бы ещё и предварительно агрегировать данные, а не грузить оригинал)

это лучше делать всегда) у меня вон приходят отчёты от разных сетей в конце месяца в виде выгрузок в эксель. так это дичь с ними прямо работать. приходится всё заливать в единую базу. т.к. скормить обработку экселей pbi так себе затея.

Со всегда не согласен, может быть предварительная обработка где-то занимает больше времени, чем трансформация в pbi

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

у вас, судя по всему, куча файлов, и да, тут нужно хранилище по-хорошему, но вот если файлов 10, то нафига))) По этому я и не согласен со "всегда"

утреца, а в чатике есть представители visiology - vixtract? :D

коллеги, привет. внезапно столкнулась в новой для себя задачей и начала тормозить. нужно в режиме directquery (это критично) считать для графика сумму на неделю назад. с ходу-то всё просто, например CALCULATE([мера], DATEADD('dates'[date], -7, DAY)), но вот такие относительные формулы в DQ генерят очень неприятные запросы в базу. Доки говорят нам использовать относительный столбец, но это же больше про "отобразить в отчете только текущий месяц", например? чтобы не использовать relative filter в filter pane, а сделать явную фильтрацию, которая и отберет нужный период https://docs.microsoft.com/en-us/power-bi/guidance/directquery-model-guidance
Или это можно и для моей задачи применить?
Еще возникла идея повесить к календарю доп. столбец в базу (рядом с датой) - "дата минус неделя", "дата минус месяц" и так далее. и сделать неактивную связь (насколько я вижу, их использование систему не нагружает) и использовать в вычислениях их.

в общем, есть ли те, что в dq активно сравнивает периоды в истории и как вы это делаете оптимально? спасибо

К слову, для истории, в live connection это никаких проблем не вызывает (хотя это достаточно понятно)

это как-то зависит от источника? если в связке использовать azure sql, например, то запрс всё равно не оптимально делается?

У меня как раз azure sql)

запрос всё равно не оптимально делается?

Насколько я помню, это и с azure sql, и с synapse. Не microsoft источники сейчас не рассматриваю

Да, именно.

Но об это и доки говорят

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

да вроде

https://www.daxpatterns.com/time-patterns/
например, если задача "считать для графика сумму на неделю назад. с ходу-то всё просто, например CALCULATE([мера], DATEADD('dates'[date], -7, DAY))" и речь идет о стандартной задаче сравнения со сдвигом на неделю, то я бы решал так:

=
VAR _Begin =
    MIN ( Calendar[Date] )
VAR _End =
    MAX ( Calendar[Date] )
RETURN
    CALCULATE (
        [measure],
        Calendar[Date] >= _Begin - 7,
        Calendar[Date] <= _End - 7,
        ALL ( Calendar )
    )

или аналог с FILTER

Ребят, подскажите формулу которая считает количество упоминаний в столбце, у меня есть список клиентов мне надо посчитать сколько раз этот id покупал сколько товаров и на какую сумму, чё не догоняю как это сделать