15 Replies Latest reply: Nov 10, 2014 2:13 AM by Vadim Tsushko RSS

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

    Denis Irhin

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

       

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

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

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

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

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

       

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

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

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

       

      Спасибо.

        • Re: СрезПоследних оптимальный метод
          Eugeny Ilyin

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

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

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

            • Re: СрезПоследних оптимальный метод
              Denis Irhin

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

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

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

               

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

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

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

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

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

                • Re: СрезПоследних оптимальный метод
                  Vadim Tsushko
                  Сейчас методика такова - выгружаем все объекты в 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

                    • Re: СрезПоследних оптимальный метод
                      Denis Irhin

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

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

                       

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

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

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

                       

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

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

                      • Re: Re: СрезПоследних оптимальный метод
                        Eugeny Ilyin

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

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

                          • Re: СрезПоследних оптимальный метод
                            Vadim Tsushko

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

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

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

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

                              • Re: СрезПоследних оптимальный метод
                                Eugeny Ilyin

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

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

                                 

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

                                  • Re: СрезПоследних оптимальный метод
                                    Vadim Tsushko

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

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

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

                                     

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

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

                        • Re: СрезПоследних оптимальный метод
                          Denis Irhin

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

                          Согласно документа HIC есть 4 метода создания BridgeTable(в случае связи многие к многим) или соединения BridgeTable с TransactionTable(в случае когда одна TransactionDate попадает только в один Interval:

                          1. IntervalMatch.
                          2. While loop creating enumerable values.
                          3. JOIN.
                          4. While with Peek from FactTable.

                          Понятно, что каждые имеют преимущества, описанные в документе.

                          Я попробовал с 1 по 3 на такой задаче

                          Есть Таблица Продажи.

                          Надо присоединить к ней слева Цены для номенклатуры, установленные на дату продажи.

                          ТаблицаЦен - РегСведЦеныНоменклатуры в 1С.

                          230 000 строк продаж и чуть больше строк цен.

                          1. 45сек
                          2. Не применим - интервалы очень длинные Mapping Table получается очень большая.
                          3. 25сек.
                          4. Должен работать лучше чем 2й, но думаю все равно проиграет 1му и 3му.

                          В данном случае(интервалы длинные) Join сильно выиграл.

                           

                          По ходу были с Join были добавлены составные ключи(по документу HIC)  с помощью AutoNumber и AutoNumberHash128, которые замедлили время выполнения до 45сек, что говорит о том, что Qlik очень эффективно сам работает с ключами даже текстовыми полями типа ссылок на объекты 1С.

                           

                          Поделитесь, пожалуйста, опытом каким методом решаете такие задачи и почему.

                          Спасибо.

                            • Re: СрезПоследних оптимальный метод
                              Eugeny Ilyin

                              День добрый.
                              Какова цель иметь отдельную таблицу по ценам для факта продаж? Факт продажи свершился по цене на дату продажи, она и записана в таблице фактов.
                              Требуется сопоставить динамику цен и динамику продаж?
                              В таком случае может быть стоит рассматривать прайс не как справочную таблицу, а как еще одну таблицу фактов?

                                • Re: СрезПоследних оптимальный метод
                                  Denis Irhin

                                  Евгений, Здравствуйте.

                                  В данном случае задача была взята как пример, чтобы можно было оценить быстроту каждого из способов.

                                  Но в ней есть и практический смысл.

                                  1. Цена Розницы минус цена Факта = размер Скидки

                                  2. Факт минус нормативная себестоимость(это тип цен)  = нормативная маржа

                                   

                                  В документе HIC обсуждается вопрос хранить ли таблицу отдельно или присоединять.

                                  В случае когда одно событие происходит во многих интервалах и один интервал распространяется на многие события данные рекомендуется хранить в отдельных таблицах, связывая их BridgeTable.

                                  А когда одно событие ре надлежит одному интервалу, то рекомендуется join. Это как раз этот случай.

                                   

                                  Спасибо.

                                • Re: СрезПоследних оптимальный метод
                                  Vadim Tsushko

                                  Денис, добрый день.

                                   

                                   

                                  Поделитесь, пожалуйста, опытом каким методом решаете такие задачи и почему.

                                   

                                  К сожалению обоснованных цифрами и фактами предпочтений по этому вопросу у меня нет.

                                  Предпочтение по факту - чаще всего используем IntervalMatch.

                                  У HIC в качестве отрицательной стороны этого подхода приводится необходимость использования закрытых диапазонов - для себя я в этом особенно ничего плохого не вижу. Чаще всего, как и в вашем случае, создание диапазонов из реестра событий (по тому же шаблону http://community.qlik.com/blogs/qlikviewdesignblog/2013/02/25/creating-intervals-from-change-dates) это просто промежуточный этап.

                                  Метод с JOIN на наборах данных по проводкам использовать опасаемся. Создание картезианского произведения двух больших наборов данных требует много памяти, причем эти требования растут нелинейно при росте исходных наборов данных. Хотя его можно без опаски использовать в скриптах, где размеры наборов данных легко предсказуемы - как например в скрипте для создания мастер календаря Calendar with flags making set analysis so very simple