[Polinik]

Mircy z #powerbi, mam 2 formuły kolumny obliczeniowej w DAX, obie wyliczają to samo -- udział ilości danego rekordu do sumy ilości transzy do której należy dany rekord.
Transze są dwie na tydzień, więc unikalną transzę (i jej sumę) identyfikuję przez sumę warunków tydzień+transza.

Obie formuły działają prawidłowo, zastanawiam się tylko czy jest między nimi jakaś różnica, która przemawia na korzyść jednej bądź drugiej?
Jedna to SUMX + FILTER, druga to CALCULATE z SUMX.
Tak na czuja to skoro CALCULATE i tak wewnętrznie tłumaczy składnię warunków na FILTER to właściwie chyba obie funkcje sprowadzają się do tego samego -- bierzemy tabelę, okrajamy ją do tabeli, której wiersze spełniają dwa warunki i sumujemy jedną z kolumn.

W tematach DAXowych dopiero zaczynam dłubać, wolałbym sobie wyrabiać prawidłowe nawyki, zamiast zadowalać się pierwszą rzeźbą, która działa.

#businessintelligence

[excelfinance]

@Polinik: Mogę pierdzielić głupoty wiec niech mnie ktoś w razie czego poprawi ale wg mnie różnica będzie w kontekście. Calculate tignoruje filter context wiec w zależności jaki będzie filter context to co innego może się pokazać. Pod względem optymalizacyjnym nie mam pojęcia.

[Sad_poyato]

@excelfinance: @Polinik:

W tym przypadku prawdopodobnie nie będzie różnicy, algorytm wygeneruje zbliżone lub identyczne kwerendy, ale każdy przypadek użycia trzeba rozpatrywać indywidualnie.

Użycie calculate w kolumnie kalkulowanej powoduje, że filtr wiersza jest przekształcany w filtr kontekstu (tutaj zmodyfikowany ALL'em który znów go usuwa. W przypadku Fillter bez calculate'a kalkulacje są robione od razu na pełnym zbiorze. W każdym razie optymalizacja kodu na poziomie kolumn kalkulowanych nie wpływa na performance raportu

[Polinik]

@excelfinance:

CALCULATE nie ignoruje kontekstu filtra -- CALCULATE go modyfikuje w tym zakresie, który jest wskazany w argumentach.

W moim przypadku co prawda daję ALL(tabela), więc faktycznie każę mu ignorować filtry i równocześnie nałożyć dwa filtry, ale jakbym nie miał ALL i zostawił tylko 2 warunki (RT i TRANSZA) -- to zewnętrzne filtry były by zmodyfikowane tylko, jeśli też dotyczyłyby RT i Transza. Jeżeli zewnętrzny filtr tyczyłby się np. koloru --

[Polinik]

@Sad_poyato:
Dzięki za odpowiedź. Rozważam różnice rzecz jasna odnośnie kolumny obliczanej. Dzięki za wyjaśnienia.
Wyżej rozpisałem, czemu wydaje mi się, że obie funkcje właściwie robią to samo -- najpierw generują identyczne tabele a potem sumują jedną z kolumn.
Różnica łopatologicznie chyba taka, że SUMX+FILTER bierze całą tabelę i filtruje rekordy, a CALCULATE bierze przefiltrowaną tabelę, usuwa filtr, nakłada swój i sumuje rekordy? Ale na kroku przed sumowaniem -- obie funkcje tworzą

[Sad_poyato]

@Polinik:

W moim przypadku co prawda daję ALL(tabela), więc faktycznie każę mu ignorować filtry i równocześnie nałożyć dwa filtry, ale jakbym nie miał ALL i zostawił tylko 2 warunki (RT i TRANSZA) -- to zewnętrzne filtry były by zmodyfikowane tylko, jeśli też dotyczyłyby RT i Transza. Jeżeli zewnętrzny filtr tyczyłby się np. koloru -- to bez ALL dalej by było filtrowanie po kolorze, tylko jeszcze dodatkowo po RT i TRANSZA.

Tak

[Polinik]

@Sad_poyato: supcio, dzięki za wyjasniwnia

[Polinik]

@Sad_poyato:
Jeśli mogę jeszcze dopytać (bo też trochę doczytałem i poćwiczyłem).

CALCULATE zamienia kontekst wiersza na kontekst filtru, czyli każda wartość w danym wierszu stanie się filtrem. Wszystko jasne. Ale konsekwencją jest to, że jeśli mamy 2 identyczne wiersze (np. ten sam klient, ten sam dzień, ta sama ilość) -- to CALCULATE zwróci oba wiersze. To też jasne, jest nawet w podręczniku opisane.

Ale to, czego nie ma -- czy to

[Sad_poyato]

@Polinik wystąpienie takiego problemu jest niezwykle rzadkie, bo po pierwsze, musiała by wystąpić potrzeba zbudowania kolumny kalkulowanej na tabeli faktowej, która iterowała by, przez tą tabelę. Po drugie, tabela musiała by zawierać niezagregowane surowe dane bez ID\indexu. Po trzecie musiałby sie zdążyć taki przypadek, ze akurat 2 lub wiecej wierszy bedzie miało tą samą konfiguracje.

W całej karierze nie zdążył mi się taki przypadek w realnych projektach. Zazwyczaj odpowiednie przygotowanie danych to