Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Здравствуйте.
Это должна быть популярная задача присоединить к таблице фактов значение реквизите меняющееся во времени.
В 1С это делает функция СрезПоследних
ТаблицаФактов - регистр накопления ВзаиморасчетыСРаботниками
Подразделение берем из регистра сведений УчетЗаработкаРаботников
В таблице фактов остаются только те значения, которые имеют запись в УчетЗаработкаРаботников - для упрощения
В приложении один из методов решения.
Уверен, что есть более красивые и более быстрые методы решения.
Предложите, пожалуйста.
Спасибо.
Сейчас методика такова - выгружаем все объекты в qvd и оставляем 1С заниматься своим делом - не загружая ее. Дальше решаем методами Qlik.
Мне этот подход кажется оптимальным. Как можно более щадящие запросы из оперативной базы (по сути неважно какая именно корпоративная система используется в качестве ERP) и вся дальнейшая обработка средствами QlikView.
Как вариант думали над преобразованием РегСведения в таблицу не только с датой начала, но и с датой окончания и последующей загрузкой с помощью префикса IntervalMatch. Но пока не сделали и не знаем насколько это будет красивее или производительней
Для такого рода преобразования мы используем вот этот шаблон: http://community.qlik.com/blogs/qlikviewdesignblog/2013/02/25/creating-intervals-from-change-dates
Ну и в целом на мой взгляд проблема классифицирована и хорошо описана тут: IntervalMatch and Slowly Changing Dimensions
Спасибо, интересное решение.
Возникло сомнение по поводу фразы "Приходится join таблицы. QV не умеет делать сравнение значений полей двух РАЗНЫХ таблиц. А по каждой записи ходить долго."
А если предварительную обработку делать на уровне SQL-запросов при формировании хранилища, Не будет ли это эффективнее?
Евгений, Спасибо.
Идея хорошая - подумаем.
Сейчас меиодика такова - выгружаем все объекты в qvd и оставляем 1С заниматься своим делом - не загружая ее. Дальше решаем методами Qlik.
Задача на тему как получить результат методами Qlik.
Я думаю, в Qlik комьюнити должно быть много решений на эту тему.
Как вариант думали над преобразованием РегСведения в таблицу не только с датой начала, но и с датой окончания и последующей загрузкой с помощью префикса IntervalMatch. Но пока не сделали и не знаем насколько это будет красивее или производительней.
Вы как раз этим методом решали предыдущую тему
Сейчас методика такова - выгружаем все объекты в qvd и оставляем 1С заниматься своим делом - не загружая ее. Дальше решаем методами Qlik.
Мне этот подход кажется оптимальным. Как можно более щадящие запросы из оперативной базы (по сути неважно какая именно корпоративная система используется в качестве ERP) и вся дальнейшая обработка средствами QlikView.
Как вариант думали над преобразованием РегСведения в таблицу не только с датой начала, но и с датой окончания и последующей загрузкой с помощью префикса IntervalMatch. Но пока не сделали и не знаем насколько это будет красивее или производительней
Для такого рода преобразования мы используем вот этот шаблон: http://community.qlik.com/blogs/qlikviewdesignblog/2013/02/25/creating-intervals-from-change-dates
Ну и в целом на мой взгляд проблема классифицирована и хорошо описана тут: IntervalMatch and Slowly Changing Dimensions
Вадим, Спасибо за указание на верное направление.
Документы HIC великолепны. Из них надо составить HICookBook+.
Ваши рекоменлации позволют применить best practice для решения задач.
Хочу поблагодарить за описание метода AsOFDate calendar - он тоже решает одну из самых необходимых потребностей.
Расчет показателя с истории времен на ДАТУ (конец месяца, квартала, года)
Тема остается открытой для альтернативных подходов к решению.
Спасибо всем Участникам.
Спасибо за теплые слова, Денис
Мне этот подход кажется оптимальным. Как можно более щадящие запросы из оперативной базы (по сути неважно какая именно корпоративная система используется в качестве ERP) и вся дальнейшая обработка средствами QlikView.
Согласен, сбор данных должен проходить как можно быстрее.
Но, какая именно КИС - важно. И даже один запрос SELECT с вычислениями и join-ами может сэкономить кучу времени и ресурсов.
Конечно есть ситуации, когда без join-ов в исходной базе не обойтись.
Представим себе высоко-нормализованную базу где нас интересуют накладные на продажу. Дата накладной имеется только в заголовке накладной, строки накладной связаны с заголовками внешним ключом.
Если исходные таблицы очень велики, и мы хотим сегментировать загрузку по периодам - наверное join будет естественным решением.
А вот вычисления ... Как то не приходит в голову. Вы можете привести какой нибудь пример, когда с вашей точки зрения целесообразно проводить вычисления в СУБД корпоративной системы?
Например, по фактическим данным:
В заголовке документа хранится признак способа расчета НДС.
В строках документа поле Sum может быть либо включая НДС либо без.
Получить реестр движений ТМЦ быстрее и проще одним запросом, чем обработкой двух таблиц в сценарии Qlikview.
Евгений, спасибо за пример.
В принципе я согласен, что обработка данных средствами СУБД корпоративной системы может быть в каком то смысле быстрее и проще.
По факту мы стараемся ее не применять. Наверное тут правильнее говорить не об оптимальности того или другого подхода вообще а об оптимальности с точки зрения каких то конкретных критериев оптимизации.
Центральный критерий для нас - оптимизация именно интерфейса между корпоративной системой и QlikView. То есть именно этап забора данных из корпоративной системы оптимизируется по времени исполнения, по нагрузке на СУБД корпоративной системы, по нагрузке на сеть. Одна из центральных задач - не повлиять на работоспособность КИС.
Дальше в ход вступает QlikView - на другом сервере, со своими собственными приемами оптимизации загрузки и т.д.