Страницы: 1
RSS
Allexcepet в сочетании с CALCULATE мера не рассчитывается из за большого объема данных, хотя фильтр минимальный
 
Здравствуйте помогите пожалуйста разобраться. В прикрепленных файлах файл с примером, который должен получиться(где все работает), (там есть рассчитанные меры: предыдущее время и предыдущее время 2) но на практике эти меры не работают файл просто виснет.:
https://1drv.ms/u/s!AsoXb9DQSkYPnnFasmjj3vJZ14N1 (рабочий файл)
Изменено: Korochaboy - 09.10.2018 13:09:57
 
У вас в этой таблице 750.000 строк. Конечно такую операцию будет делать долго и потребует много памяти.
Вам точно нужно вывести их все и посчитать для каждой строки предыдущее время?
В чем смысл? Или всё же у вас задача конечная немного другая, чем 750.000 раз посчитать предыдущее время?
F1 творит чудеса
 
Кнопка цитировани не для бездумного копирования [МОДЕРАТОР]

Задача: посчитать время приема. Для того чтобы посчитать нужно предыдущее время.
Можно делать это в рамках этого и предыдущего месяца.
Я просто думал, что он не обрабатывает все эти строки 750 000. А только те которые я добавляю на визуализацию.
Это получается мне в редакторе запросов нужно ограничивать ?
Я просто хотел загружать весь запрос, а потом уже все фильтры DAX ом
 
ИМХО, проще на этапе загрузки в модель посчитать для каждой строки время приема при помощи приема с двумя индексами и джойном и уже столбец с готовыми данными анализировать DAXом.
Вот горшок пустой, он предмет простой...
 
Сергей Новиков, во-первых, это не очень красиво выкладывать файл, в который трудно назвать рабочим, в котором куча таблиц без настроенных связей и куча не рабочих вычисляемых столбцов. Во-вторых  следует из первого - если слона есть по частям и нормально формулировать вопросы, то ответы будут более полезными.
Из того, что увидел в вашем "рабочем" файле и что смог понять:
В целом для таблицы фактов "LogMessages" есть все необходимые справочники, не хватает только календаря (может не заметил) и настроенных связей. Как я понял таблицу фактов - в ней фиксируются все статусы-движения талончика(TicketId). Соответственно минимальное время TicketId - это начало приема, максимальное время TicketId - это конец приема. Для этого достаточно элементарных мер MIN(LogMessages[CurrentTimestamp]) и MAX(LogMessages[CurrentTimestamp]) соответственно. Мера разницы между MAX и MIN будет продолжительность приема. Такое считается элементарно - у меня ничего не зависает. Сформировал таблицу: Оператор - Талон - Начало приема - Конец приема - Время приема, - выглядит все логично. По фильтру за 6е августа получилось, что первый прием в 6:59, закончили работу в 20:23. Но я так понимаю, что для расчета там надо все таки брать не все статусы талончика, но тут уже вам виднее, и это легко решается через фильтры связанных справочников.
 
Цитата
Сергей Новиков написал:
Задача: посчитать время приема.
Эта задача решается не так... Вы хотите показать время приема для каждого талона за день? Или посчитать время приема по талонам и показать что-то другое (среднее, по специалистам, еще как-то)? Это можно решить немного разными методами. Если каждый таймстемп это какие-то статусы приема (получил - ожидание - еще что-то - прием - окончание приема), то это одно, тогда можно считать для каждой строки заранее, при обновлении данных, как написал PooHkrd. Если же нужно просто найти разницу между максимальным и минимальным временем по одному талону в дату, то это не нужно делать построчно для каждого таймстемпа, надо сделать как говорит StepanWolkoff
F1 творит чудеса
Страницы: 1
Наверх