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

[Anonymous]

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

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

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

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

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

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

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

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

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

Спасибо.

[Anonymous]

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

Согласно документа 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С.

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

Спасибо.

[Eugeny_Ilyin]

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

[Anonymous]

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

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

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

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

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

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

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

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

Спасибо.

[Eugeny_Ilyin]

Денис, третий вариант - а почему сразу не сделать эти вычисления при сборе факта?

[Anonymous]

Евгений, Вы дискутировали эту тему с Вадимом.

Цель этого топика узнать эффективный метод присоединения РегСведений(в терминах 1С) или slowly changing dimensions(в терминах Qlik) методами именно Qlik.

Спасибо.

[vadimtsushko]

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

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

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

Предпочтение по факту - чаще всего используем 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