А
вот такая мера
Size: a a a
2020 June 19
TK
Oleg Poddubnyy
на визуализации хотят увидеть текущего менеджера, но с продажами по клиенту от старого менеджера 😊
Задачу начинаю понимать... А вот решить помочь, похоже, сейчас не смогу... Может, кто из коллег посоветует
А
Задачу начинаю понимать... А вот решить помочь, похоже, сейчас не смогу... Может, кто из коллег посоветует
Отдельная таблица, где несколько менеджеров к одному, потом её сджойнить и все
1
Oleg Poddubnyy
на визуализации хотят увидеть текущего менеджера, но с продажами по клиенту от старого менеджера 😊
дата изменения менеджера есть?
1
зачем Вам ее уровень в мере? что Вы хотите рассчитать в мере в конечном итоге?
А
зачем Вам ее уровень в мере? что Вы хотите рассчитать в мере в конечном итоге?
Мне шобы в прожект загнать шустро
А
Тупо нужен отдельный столбец с уровнем иерархии
MB
А мне нужно не из меры, а из столбца - это возможно?
IS
Тупо нужен отдельный столбец с уровнем иерархии
Если именно мера, то что-то типа: var _childID=MIN(Hierarh[ChildID])
return
PATHLENGTH(SELECTEDVALUE (Hierarh[HierarhPath];_childID))
return
PATHLENGTH(SELECTEDVALUE (Hierarh[HierarhPath];_childID))
IS
На третьем уровне может быть 1й, могут быть пропуски. В исходной таблице есть столбец с уровнями
🅰
Привет! Как считаете, правильно я спроектировал модель данных? У меня 3 таблицы (янв, фев, март) с одинаковым набором полей и типов данных. Я добавил столбец с датой в каждую. Остается юнион сделать и можно визуализировать?
AS
Привет! Как считаете, правильно я спроектировал модель данных? У меня 3 таблицы (янв, фев, март) с одинаковым набором полей и типов данных. Я добавил столбец с датой в каждую. Остается юнион сделать и можно визуализировать?
Лучше в PQ append сделать
AS
А потом уже гнать в визуалку
🅰
Лучше в PQ append сделать
Уже второй раз слышу о редакторах. Только зачем? Сущности все перед нами, их мало. Связи понятны. Что я упускаю в таком подходе?
AS
Уже второй раз слышу о редакторах. Только зачем? Сущности все перед нами, их мало. Связи понятны. Что я упускаю в таком подходе?
Зачем иметь 3 куска одного массива, которые всё равно потом объединяете, если можно сразу получить подготовленный для работы формат. И ресурсы меньше грузит,и связей меньше делать.
🅰
Зачем иметь 3 куска одного массива, которые всё равно потом объединяете, если можно сразу получить подготовленный для работы формат. И ресурсы меньше грузит,и связей меньше делать.
Я так и сделал в таблице факт. Хочу быть уверенным, что правильно объединил. Через юнион (подставил данные фев под янв и т.д.)
AS
Я так и сделал в таблице факт. Хочу быть уверенным, что правильно объединил. Через юнион (подставил данные фев под янв и т.д.)
Вы можете проверить оба варианта по уровню нагрузки ресурсов при вызове какой-то меры.
🅰
Меня сейчас больше модель данных с точки зрения нормальных форм интересует. Делаю почти впервые, поэтому перестраховываюсь.
AS
Но я бы рекомендовал разделять etl и pivot задачи.
Юнион - удобная функция, но данные нужно стараться готовить предварительно. Справочники Вы ведь сделали)
Но дело Ваше, конечно
Юнион - удобная функция, но данные нужно стараться готовить предварительно. Справочники Вы ведь сделали)
Но дело Ваше, конечно