СрезПоследних оптимальный метод

[Anonymous]

Здравствуйте.

Это должна быть популярная задача присоединить к таблице фактов значение реквизите меняющееся во времени.

В 1С это делает функция СрезПоследних

ТаблицаФактов - регистр накопления ВзаиморасчетыСРаботниками

Подразделение берем из регистра сведений УчетЗаработкаРаботников

В таблице фактов остаются только те значения, которые имеют запись в УчетЗаработкаРаботников - для упрощения

В приложении один из методов решения.

Уверен, что есть более красивые и более быстрые методы решения.

Предложите, пожалуйста.

Спасибо.

[Eugeny_Ilyin]

Спасибо, интересное решение.

Возникло сомнение по поводу фразы "Приходится join таблицы. QV не умеет делать сравнение значений полей двух РАЗНЫХ таблиц. А по каждой записи ходить долго."

А если предварительную обработку делать на уровне SQL-запросов при формировании хранилища, Не будет ли это эффективнее?

[Anonymous]

Евгений, Спасибо.

Идея хорошая - подумаем.

Сейчас меиодика такова - выгружаем все объекты в qvd и оставляем 1С заниматься своим делом - не загружая ее. Дальше решаем методами Qlik.

Задача на тему как получить результат методами Qlik.

Я думаю, в Qlik комьюнити должно быть много решений на эту тему.

Как вариант думали над преобразованием РегСведения в таблицу не только с датой начала, но и с датой окончания и последующей загрузкой с помощью префикса IntervalMatch. Но пока не сделали и не знаем насколько это будет красивее или производительней.

Вы как раз этим методом решали предыдущую тему

Re: Подсчет сотрудников имея записи о приеме и увольнении

[vadimtsushko · Accepted solution]

Сейчас методика такова - выгружаем все объекты в 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

[Anonymous]

Вадим, Спасибо за указание на верное направление.

Документы HIC великолепны. Из них надо составить HICookBook+.

Ваши рекоменлации позволют применить best practice для решения задач.

Хочу поблагодарить за описание метода AsOFDate calendar - он тоже решает одну из самых необходимых потребностей.

Расчет показателя с истории времен на ДАТУ (конец месяца, квартала, года)

Тема остается открытой для альтернативных подходов к решению.

Спасибо всем Участникам.

[vadimtsushko]

Спасибо за теплые слова, Денис

[Eugeny_Ilyin]

Мне этот подход кажется оптимальным. Как можно более щадящие запросы из оперативной базы (по сути неважно какая именно корпоративная система используется в качестве ERP) и вся дальнейшая обработка средствами QlikView.

Согласен, сбор данных должен проходить как можно быстрее.
Но, какая именно КИС - важно. И даже один запрос SELECT с вычислениями и join-ами может сэкономить кучу времени и ресурсов.

[vadimtsushko]

Конечно есть ситуации, когда без join-ов в исходной базе не обойтись.

Представим себе высоко-нормализованную базу где нас интересуют накладные на продажу. Дата накладной имеется только в заголовке накладной, строки накладной связаны с заголовками внешним ключом.

Если исходные таблицы очень велики, и мы хотим сегментировать загрузку по периодам - наверное join будет естественным решением.

А вот вычисления ... Как то не приходит в голову. Вы можете привести какой нибудь пример, когда с вашей точки зрения целесообразно проводить вычисления в СУБД корпоративной системы?

[Eugeny_Ilyin]

Например, по фактическим данным:

В заголовке документа хранится признак способа расчета НДС.
В строках документа поле Sum может быть либо включая НДС либо без.

Получить реестр движений ТМЦ быстрее и проще одним запросом, чем обработкой двух таблиц в сценарии Qlikview.

[vadimtsushko]

Евгений, спасибо за пример.

В принципе я согласен, что обработка данных средствами СУБД корпоративной системы может быть в каком то смысле быстрее и проще.

По факту мы стараемся ее не применять. Наверное тут правильнее говорить не об оптимальности того или другого подхода вообще а об оптимальности с точки зрения каких то конкретных критериев оптимизации.

Центральный критерий для нас - оптимизация именно интерфейса между корпоративной системой и QlikView. То есть именно этап забора данных из корпоративной системы оптимизируется по времени исполнения, по нагрузке на СУБД корпоративной системы, по нагрузке на сеть. Одна из центральных задач - не повлиять на работоспособность КИС.

Дальше в ход вступает QlikView - на другом сервере, со своими собственными приемами оптимизации загрузки и т.д.