Добрый день.

Вопрос не влез в заголовок.

Сферический конь в вакууме:

Есть справочник магазинов. Есть инфа по акциям (сама акция - это документ, в нем период действия , всякие условия, (2 даты - типа с начала декабря по конец декабря), и длинная табличная часть со списком магазинов, тысячи их может быть)

Вопрос - как мне ускорить запрос "Какие акции есть 10 декабря в таком-то магазине"?

Думаю сделать регистр сведений, с измерением магазин, акция, и ДатаНачала и ДатаКонца.

Но меня смущает что 2 даты - регистр делать получается не периодический?
Имеет ли смысл делать индексацию полей?
Быстрее будет сделать отбор по магазину, положить во временную таблицу, и дальше делать отбор по датам?
Или сразу наложить отбор "ДатаЗапроса>=ДатаНачала" и "ДатаЗапроса<=ДатаКонца"?
Или лучше вообще при проведении документа типа "акция на декабрь" писать в регистр 31 запись на каждый магазин, на каждый день? Но так что-то совсем дохрена записей будет

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

(0) периодический регистр
или 2 записи: начало и конец с ресурсом состояния,
или начало в период конец в ресурс.
Проверка в любом случае срезом

Изучи как устроен регистр с кадровыми данными физлиц в ЗУПе.

Так к ТЧ справочника и сделай запрос

Если это задача оперативного учета и необходимо знать текущие действующие прямо сейчас акции, то я бы отказался вообще от дат с указанием периода действия, а хранил бы только актуальные акции, которые действуют.
В другом регистре хранил бы все данные (вместе с периодом действия) и регламентным заданием каждую ночь в 00:01:00 обновлял бы данные из регистра с периодами данные в оперативном регистре.
Естественно оперативный регистр не периодический.

Но этот изврат имеет смысл, только если производительность действительно критична. В противном случае, например см.(2).

(0) Ну допустим: Регистр сведений, периодический(в пределах дня), подчинен регистратору. Измерения: Организация, Получатель (Контрагент или Партнер, или что там у вас в конфе), Номенклатура/Набор номенклатуры, измерение или несколько измерений с условиями акции, Ресурсы: ЗначениеСкидки(если скидка) или Бонус(если скидка натуральная, т.е. другим товаром), Реквизиты: ДатаОкончания(для ограничения результата СрезПоследних).

Самый смак будет, когда захочется узнать какие акции действуют не на конкретный момент времени, а в заданном интервале

+(6) Так что проиндексировать придется оба поля с датами

А уж куда ты их там засунешь - в ТЧ, в реквизиты / ресурсы / измерения периодического / непериодического независимого / зависимого регистра - с этой точки зрения особо не влияет

Нужно скорее всего будет и на дату, и на период дат и т.д.

(8)То есть скорость будет в основном зависеть от того, индексируемые поля или нет?

(10) Взял бы уже и давно план своего требующего ускорения запроса посмотрел. Сколько строк затронуто, скан там или сик, кластерного или некластерного.

(11)База серверная, постгрес. Сколько строк будет пока не знаю, хочется изначально технически правильно сделать.

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

Создаю тестово 1000 документов по 2000 строк. Не то что фузиновцы

(12) По скорости будет разницы не будет. Что ты по ТЧ запрос сделаешь, что по регистру

(0) РС прям как ты описал, порядок измерений другой

Магазин, ДатаНачала и ДатаКонца, акция.

Ничего индексировать не надо.

(12) "лезть в табличную часть документов это совсем не оптимальный запрос, поэтому и спросил - будет ли лучше сделать регистр сведений?" // С точки зрения производительности чтение ТЧ и чтение регистра - это чтение одной плоской таблицы.
(14) Отличия только в неотключаемых (из коробки) индексах, если читающий запрос в обоих случаях попадает в индекс более-менее одинакового размера и структуры, то отличый быть не должно.

(15) Не думаю, что он догадается (по крайней мере планировал) делать дату конца измерением

(18)так мне же на Мисте уже так насоветовали. Ща вот проверяю, будет ли толк

(0) в ЗУПЕ такие задачи успешно решают технологией "интервальные регистры сведений" и всякие периодические оттуда почти выпилены.

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

интересно появятся в 1с произвольные составные индексы? тогда и без регистра сведения можно было бы обойти

регистр остатков :)

документ старта акций делает + на начало акции и - на конец

Но все равно же пихать в измерение ссылку на сам документ (на акцию).

(23) ну да

Замеры:
1000 документов по 2000 строк

Запрос "какие акции действуют на выбранном 1 магазине на конкретную дату"

В каждом варианте сделал по 10 замеров времени, выбрал среднее

1)Запрос напрямую к магазину в табличной части + отбор по "ДатаЗапроса>=Акция.ДатаНачала" и "ДатаЗапроса<=Акция.ДатаКонца"

В среднем 0.15 секунд

2)Запрос к срезу последних регистра сведений, где ресурс "Статус акции" = Активна/Кончилась

В среднем 0.017 секунд

Но увеличение объема данных соответственно, за счет записей в регистр + время на проведение документа

(25) Покажи запрос 1) Явно где то косяк.

(25) на самом деле можно отказаться от тч, а сделать вместо неё программную таблицу и заполнять её из регистра при чтении а при записи - распихивать прямо в набор обратно. проведение и непроведение пусть рулит только галочкой активности.

а сами записи в РС пусть будут всегда

(27) Галочка "Активность", не входящая в кластерный индекс, тебе потом спасибо скажет.

(29) ну зачем-то же её придумали... и в типовых в операции бух она используется.

в крайнем случае можно пихать у непроведенного документа в тч а при проведении удалять из тч и пихать в рс. при отмене проведения - делать обратное преобразование.

если размер прям критичен

(25) пиши каждую дату из периода (РС (Магазин, ДатаДействия, Акция)) - будет самое быстрое

тысячи строк - это нично.
вот если бы миллионы были

В ЗУПе уже все придумали. Когда уже они пихнут это в БСП...

(26)Первый вариант:

Запрос.Текст =
        "ВЫБРАТЬ
        |    АкцииПокупатели.Ссылка
        |ИЗ
        |    Документ.Акции.Покупатели КАК АкцииПокупатели
        |ГДЕ
        |    АкцииПокупатели.ТорговаяТочка = &ТорговаяТочка
        |    И АкцииПокупатели.Ссылка.ДатаН <= &ДатаЗапроса
        |    И АкцииПокупатели.Ссылка.ДатаК >= &ДатаЗапроса";

(26)Второй вариант

Запрос.Текст =
        "ВЫБРАТЬ
        |    АкцияСрезПоследних.Акция КАК Ссылка,
        |    АкцияСрезПоследних.ТорговаяТочка
        |ИЗ
        |    РегистрСведений.Акция.СрезПоследних(&ДатаЗапроса, ТорговаяТочка = &ТорговаяТочка) КАК АкцияСрезПоследних
        |ГДЕ
        |    АкцияСрезПоследних.Статус = &Активна";

(33)Переживаю что при установке акции на год на 2000 магазинов получу 2000*365 = 730000 записей

А так в принципе сделал примерно как ЦеныНоменклатуры регистр

при первом приближении:
зачем эта периодичность вообще?
я бы сделал непериодический регистр сведений
измерения:
магазин, дата начала и дата окончания.
ресурс: естьакция - булево
или вообще без ресурсов,
показатель наличия акции на магазин - присутствие магазина в заданном интервале
соответственно, индекс на даты и магазины в измерениях.

запрос внутренним джойном по магазинам и по наличию в заданном интервале

(38) Всего то, даже миллиона нет, нашел о чем переживать

(37) А если дату окончания засунуть в ресурс и заменить условие на статус заменить на АкцияСрезПоследних.ДатаОкончания >= &ДатаЗапроса?
Записей станет в два раза меньше, интересно, асколько условие будет медленнее/быстрее

(36) Так неправильно делать. нужно примерно так.
ВЫБРАТЬ
    ЗаказПокупателя.Ссылка КАК Ссылка
ИЗ
    Документ.ЗаказПокупателя.Товары КАК ЗаказПокупателяТовары
        ЛЕВОЕ СОЕДИНЕНИЕ Документ.ЗаказПокупателя КАК ЗаказПокупателя
        ПО ЗаказПокупателяТовары.Ссылка = ЗаказПокупателя.Ссылка
ГДЕ
    ЗаказПокупателя.Дата МЕЖДУ &Дата1 И &Дата2
    И ЗаказПокупателяТовары.Номенклатура = &Номенклатура

+ (43) Только не "ЛЕВОЕ СОЕДИНЕНИЕ", а "ВНУТРЕННЕЕ СОЕДИНЕНИЕ"

+(44)
ВЫБРАТЬ
    Акции.Ссылка КАК Ссылка
ИЗ
    Документ.Акции.АкцииПокупатели КАК АкцииАкцииПокупатели
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.Акции КАК Акции
        ПО АкцииАкцииПокупатели.Ссылка = Акции.Ссылка
ГДЕ
    &ДатаЗапроса МЕЖДУ Акции.ДатаН И Акции.ДатаК
    И АкцииАкцииПокупатели.ТорговаяТочка = &ТорговаяТочка

(45)Примерно тоже самое получилось (по скорости). О,15 секунд

(45) так может условия тогда в связи перенести? Иначе непонятно для чего явное соединение и чем оно лучше неявного в(36)

1. а фильтр по товару не интересен?
2. 0,15 сек на получение 1000 записей не такой плохой результат
3. почему период - на практике должна интересовать конкретная дата а не период

(47)Так мне по датам отбор делать надо, а даты это реквизит документа. То есть если в табличной части делать отбор через ссылку документа - платформе уже надо опять лезть в документ, кроме таблицы табличной части. А если не делать отбор в табличной части - что он потянет? Всю таблицу?

(49) просто попробуй в (45) "ГДЕ" заменить на "И" и покажи замер

Тебе надо постоянно вычислять список акций текущего магазина, или достаточно раз в сутки его вычислить, а всю смену получать готовый список?

(48)
1. Там уже в документе дохренища вариантов этих акций, условий и т.д. Может и нужно будет
2. Ну это да, но в тестовой базе я один сижу, то есть она больше сейчас ничем не нагружена.

Потом как установлю - могу для интереса провести тесты еще на боевой базе, под нагрузкой. Наверняка будет медленней.

3. В данном случае нужна конкретная дата, да.


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

(50) 0,16 секунд

(51)Нужно много раз в день. Поступают некие документы типа "Заказ" и нужно высчитывать какие там скидки и т.д.

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

а если в самый быстрый вариант добавить Первые 1

(52) зато на рабочей базе кэш горячий

(53) Значит явное соединение плюсов не дает. Можно ещё попробовать сначала выбрать в ВТ документы с нужными периодами, а потом соединить с ТЧ.

(25) Тебя результат с регистром не устраивает? Зачем дальнейшие поиски?

(55)Акций в магазине может быть несколько (штук 10 например), нужны все, для дальнейших расчетов

(57)Кстати с явным соединением вообще все плохо.

Как-то писали в 1С, что "рекомендуем использовать временные таблицы" или чет такое.

И сам замечал много раз, что использование временных таблиц в соединениях практически всегда дает повышение производительности, хотя по идее на помещение данных во временную таблицу уходит и время и память, но все равно быстрее получается

(57)

Ищу истину.

(60) Ну пока что ты нашел - регистр быстрее.
Осталось понять тормоза из-за соединения или из-за индексов регистра.

Проверить соединение довольно просто - засунуть даты в ТЧ, соединение не понадобится. По крайней мере пока не надо будет проверять проведенность документа) - для теста пойдет

(59) Что значит "вообще все плохо" - результат же такой же.
В твоем случае объем ВТ будет явно меньше исходных таблиц, поэтому эффект может быть положительным

(60) Индексы учего есть?
1) Акции.ДатаН
2) Акции.ДатаК
3) АкцииАкцииПокупатели.ТорговаяТочка

(63)
Так, стопе

В документе ничего не индексировалось, включил индексацию ДатаН, ДатаК, ТорговаяТочка - запрос к документам стал выполняться 0,07 сек

То есть раз в 20 быстрее.

Ничего не понимаю.

Неужели все волшебство в индексах? Чем это чревато может быть?

(64)Тьфу, не в 20 раз, а в 2 раза.

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

(0) Может бред, но регистр накопления (остаток):
+ Дата1, Магазин, Акция, 1
- Дата2, Магазин, Акция, 1

(67) А лучше РСВ по позиции регистратора, т.к. акция же может корректироваться после утверждения и даты поменяться?
Магазин, Акция, Событие +, в ресурсах Дата1.
Магазин, Акция, Событие -, в ресурсах Дата2.