Avg({<price={"<1000"}>} price)

Вот это дало желаемый эффект, спасибо! А если усложнить - скажем, цена товара колеблется в районе 90-120 рублей. Один челоек ошибся и указал 1000 (это мы отсекли вот этим примером), другой написал 10, как лучше всего построить проверку отклонения?

В скрипте if(price>1000,1,0) as PriceFlag. Далее в формуле avg ({<PriceFlag={1}>} Price) даст сразу нужный датасет. Соответственно, вы можете также вывести таблицу проверок, где увидите цены, отфильтруйте по 1, и по 0, увидите и правильные и неправильные цены. Если есть мастертаблица цен, можно докрутить проверку в скрипте апплаймапом.

Случайные ошибки, можно именно так отловить, писать автопроверщики без знания всех возможных вариантов ошибок, будет крайне сложно.

Да, со скриптом лучшее решение, пожалуй. Заодно можно будет отображать тех, кто косячит с данными. Спасибо!

Еще классно работало, на одном проекте, менеджер кажлое утро получал на имейл отчет из клика, какие цены введены некорректно, по мнению системы, и пользователь правил в источнике. Что такое некорректно? Опять же некий набор правил, который позволяет вычислить, например у нас была проверка периодов действия цены, сумм по чеку и по прайсу, и вылавливались отклонения вида неверно введена валюта, например 1000 баксов против рублей, или сумма, для подобной категории максимум по прайсу 8234, а в цене 30000 в факте, что-то не то. Все такие строки собирались в отчет и высылались на выверку > далее исправить в источнике.

Мы подобные вещи в SQL делали, в QV я пока слишком молод @ зелен) спасибо!

на том проекте скул был неприкосновенный источник, ток на выход

Коллеги, может быть устроить какой-то онлайн вебинар, по формату этого чата, 1-3 специалиста будут отвечать на любые вопросы из области клика и сенса. Если я буду участвовать, моя задача обучить, пояснить, дать вектор, как искать и находить решения для клика, как моделировать задачу. Что думаете? Интерены будут такие непереодические вебинары? Точнее наверное, лайв стримы. И название будет, стрим из клик биай чата.

Многие на удаленке, многие дома. А такой формат, очередной способ расшарить знания и лично пообщаться голосом.

Если комьюнити отзовётся, то могу первую сессию устроить хоть в эту пятницу. А можно еще в субботу или воскресенье)

я +

Супер. Кто успеет, сможет загадать желание, став онлайн между двух Евгениев)

Коллеги, пишите, если вам действительно это нужно, то организуем всё 👍

+

Из моего опыта, DISTINCT практически всегда медленный, а на больших данных - очень медленный.

А что касается поведения DISTINCT в комбинации с JOIN, CONCATENATE, и т.д. - нужно просто запомнить что DISTINCT применяется к конечному результату загрузки. Более того, DISTINCT становится атрибутом таблицы и применяется и после первоначальной загрузки - что бы мы ни делали, эта таблица уже всегда будет DISTINCT...

Это я и имел ввиду под наследованием. Применив, вся таблица станет дистинкт.

Так, а если у нас есть таблица distinct с новыми данными, и мы её конкатенируем к большой базе - вся база станет distinct?

Насколько я помню, нет - свойство DISTINCT не переходит от одной таблицы к другой, как коронавирус :-) Впрочем, это очень легко проверить, не так ли?