0. Rustig 1416 26.07.13 02:07 Сейчас в теме

Большие запросы: взгляд на проблему

Большой (кусочный) запрос подобен карточному домику: строится долго, а захочется поменять карту из середины строения – домик разрушится. На примере учета задолженностей контрагентов в разрезе полугодий (не типовой учет БП, и не ЗУПовский) я покажу, как я изменил механизм учета и превратил «большой» запрос в «маленький», а дальнейшее сопровождение программы в сказку 1С-ника.

Перейти к публикации

Вознаграждение за ответ
Показать полностью
Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Арчибальд 2710 26.07.13 10:24 Сейчас в теме
2. zfilin 2158 27.07.13 00:22 Сейчас в теме
О! Декомпозиция, модульность, изоляция кода!
Спасибо, это отлично. Концепцию третьей схемы беру на вооружение.
Где-то пару раз "бессознательно" я так и поступал, но не выделил так четко в "архитектурный шаблон". Теперь все стало на место.
12. AlexO 128 28.07.13 22:32 Сейчас в теме
(2) zfilin,
О! Декомпозиция, модульность, изоляция кода!

Вы что, до этого не программировали?
(9)
Вспомогательные регистры служат для хранения промежуточно-рассчитанной информации.

Было бы все намного проще, если бы никто не развивал "концепции 1С", а просто сделали те же самые промежуточные расчеты, разбив простыни запросов на мелкие и упорядочив это все в дополнительные функции.
odin777; u_n_k_n_o_w_n; +2 Ответить
17. Rustig 1416 29.07.13 10:35 Сейчас в теме
(12)
сделали те же самые промежуточные расчеты, разбив простыни запросов на мелкие и упорядочив это все в дополнительные функции


:) спасибо за комментарий, надеюсь вашу рекомендацию услышат 1С-ники - разработчики типовых конфигураций.

что касается меня, то по возможности я так и делаю в своих задачах - разбиваю потенциально большой запрос на мелкие. Причина проста - я не силен в больших запросах, и быстрее набросать мелкие запросы.
Заметил две особенности:
1) скорость обработки информации увеличивается. Поэтому в тех задачах, где не критична скорость обработки данных, метод остается
2) в мелких запросах начинают повторяться пакетные запросы (временные таблицы), и для внесения совсем незначительного функционала уже требуется значительное время - проще говоря, одно и тоже приходится изменять в разных местах. Что можно было изменить за 5 минут - приходится изменять 40 минут, а то и больше, вспоминая через полгода, что там напрограммировано
3. Трактор 1198 27.07.13 00:58 Сейчас в теме
Раздел 3 ПереопределитьСтатусывыполнять не при завершении работы, а регламентным заданием.
u_n_k_n_o_w_n; JohnyDeath; +2 Ответить
4. JohnyDeath 297 27.07.13 14:19 Сейчас в теме
Всё хорошо за исключением момента, когда нужно переопределить статусы. Согласен с (3), на эту роль хорошо подойдут регламентные и фоновые задания.

Сам сейчас решаю похожие проблемы в нашей конфигурации. Пришлось даже написать обработку, в которой строится дерево зависимостей временных таблиц запроса.
5. zfilin 2158 28.07.13 01:22 Сейчас в теме
(3) Да, как сказать. Тут без пользователей и окружения наверняка сказать нельзя, когда именно следует обновлять эти данные. Если отчет не нужен чаще, например, чем раз в месяц и пользователь готов ждать, то нет особого смысла тратить ресурс на его периодический пересчет. Перед формированием - то, что нужно. Зачем нужно пересчитывать при завершении работы? Думаю, это надо спросить у уважаемого Рустема.
Мое предположение такое:
1. Все-таки пересчитывать регистры не только перед формированием, а еще когда-нибудь, чтобы пересчет перед формированием не был запредельно долгим, в случае, когда отчетом долго не пользовались.
2. Вот это "когда-нибудь" вешать на событие завершения работы для того, чтобы решение проще работало в файловом варианте, где для выполнения регламентных нужен пользователь "робот". А так можно обойтись без него.

Рустем, пролейте свет на вопрос. Зачем именно перед завершением, а не регламентом раз в сутки, например?
7. Rustig 1416 28.07.13 01:37 Сейчас в теме +0.6 $m
(5) :)
удивительно! вы все верно написали.
6. zfilin 2158 28.07.13 01:24 Сейчас в теме
А вообще это мелочи. Идея хорошоа. Вот это главное.
8. CheBurator 3418 28.07.13 01:50 Сейчас в теме
Нифига не понял... Смысл в чем..? в том, что структура (вспомогательных) регистров проектировалась "от нужд отчета"..? Не уловил связь изложенного подхода с декомпозицией большого запроса...
???
9. Rustig 1416 28.07.13 04:14 Сейчас в теме
(8) :) Вспомогательные регистры служат для хранения промежуточно-рассчитанной информации. Структура хранения информации не должна совпадать с конечными макетами различных отчетов. Но многие отчеты могут использовать одну и ту же информацию о показателях, статусах - которые как раз и нужно хранить в вспомогательных регистрах.
...чтобы не плодить громоздских запросов, которые с избытком напичканы конструкциями (пример из ЗУП)
|ВЫБРАТЬ
	|	ОблагаемаяБаза.ФизЛицо КАК ФизЛицо,
	|	ОблагаемаяБаза.Период КАК Период,
	|	ВЫБОР
	|		КОГДА ОблагаемаяБаза.ЗаГод - Предел.Размер >= 0
	|			ТОГДА ОблагаемаяБаза.ЗаГод - Предел.Размер
	|		ИНАЧЕ 0
	|	КОНЕЦ - ВЫБОР
	|		КОГДА ЕСТЬNULL(ОблагаемаяБазаПрошлогоМесяца.ЗаГод, 0) - Предел.Размер >= 0
	|			ТОГДА ЕСТЬNULL(ОблагаемаяБазаПрошлогоМесяца.ЗаГод, 0) - Предел.Размер
	|		ИНАЧЕ 0
	|	КОНЕЦ КАК СуммаПревысившаяПредел
	|ПОМЕСТИТЬ ВТБазаПревышенияДохода
Показать
10. AlX0id 28.07.13 10:30 Сейчас в теме
Хорошая схема, за исключением идеи расчета при завершении работы пользователя. С регламентниками оно как-то поинтереснее выглядит )
11. hogik 432 28.07.13 21:36 Сейчас в теме
(0)
Рустем (Rustig).
Плюс под публикацию поставил. Однако, категорически не согласен с предлагаемым способом борьбы с "большими" запросами путем переноса проблем запроса в сложность схемы базы данных. Проектирование схемы базы данных "плясками от отчета" - это пляски на поминках информационной системы.
И первый ;-) вопрос к Вам:
Каким алгоритмом формируется "регистр сведений ТребуетсяПереопределитьСтатусы" на начальном этапе внедрения, если база данных уже находится в эксплуатации?
13. AlexO 128 28.07.13 22:35 Сейчас в теме
(11) hogik,
Однако, категорически не согласен с предлагаемым способом борьбы с "большими" запросами путем переноса проблем запроса в сложность схемы базы данных

Я больше склоняюсь к мнению, что подобное больше является умствованием ради процесса, а не результата, хотя в 1С это и поощряется во всех проявлениях.
18. Rustig 1416 29.07.13 11:17 Сейчас в теме
(11) :) спасибо за обсуждение
способом борьбы с "большими" запросами путем переноса проблем запроса в сложность схемы базы данных.


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

Проектирование схемы базы данных "плясками от отчета".

Спасибо, уже успел понять, что я не на том сделал акцент. :(
а вообще всю жизнь так руководствуюсь, что структура регистров накоплений должна прежде всего отвечать на вопрос "что в итоге мы должны получить?" Чтобы понять, надо ли нам применять оборотный регистр или регистр остатков. Зачастую один и тот же документ может делать записи в два разных похожих регистра накопления, отличия механизмов в том, что оба регистра - заполненные одними и теми же данными - будут использоваться в разных отчетах. Регистры могут отличаться даже не признаком, а одним измерением. Для целей учета и вывода в разные отчеты такой подход имеет право на существование. Эту идею почерпнул из книги Радченко и использую уже столько сколько программирую (5 лет).

вопрос к Вам:
Каким алгоритмом формируется "регистр сведений ТребуетсяПереопределитьСтатусы" на начальном этапе внедрения, если база данных уже находится в эксплуатации?


Если честно, не понял вопроса. База в эксплуатации, используется вовсю регистр бухгалтерии Хозрасчетный
Надо получить из него информацию о задолженности. На самом деле регистр не предусмотрен для решения таких задач, когда одни субконто сильно завязаны на других, и поэтому в бухгалтерских остатках надо учесть это влияние. Приходится писать запросы такого порядка, как в примере (9)

Такого рода запросы я разгрузил - вывел расчет в алгоритмы общих модулей, сохранил результаты расчетов в регистре сведений. Дальше использую показатели из регистра сведений. В моем случае получилось, что структура регистра выстраивалась согласно тем показателям, которые надо было получить в отчете. Также в результате получилось, что по каждому контрагенту приходится хранить информацию по всем разрезам - сам заранее не ожидал такого - описал в статье что будет некое подобие олап-куба. Хотя олап-куб и так используется вовсю в конфигурациях, когда мы отвечаем на вопрос "в разрезе каких измерений мы хотим получать отчетную информацию?"
21. hogik 432 29.07.13 16:12 Сейчас в теме
(18)
"не понял вопроса."(с)
Рустем (Rustig).
А может я не понял Вашего алгоритма? ;-)
Вот тексты:
1) "При записи документов, ... контрагент попадает в регистр сведений ..."(с)
2) "... пришлось (через полгода) отразить в учете влияния переплат и долгов 2011 года на задолженности 2012 года"(с)
Кто и как обеспечил в 2012 году информацию 2011 года в регистре ТребуетсяПереопределитьСтатусы для контрагентов, которые НЕ попадали в регистр в 2011 году, т.к. регистра еще не было?
22. Rustig 1416 29.07.13 16:25 Сейчас в теме
(21) ясно, спасибо вам, что так глубоко вникаете в вопрос. вы правы в том, что что-то я не дорассказываю. :)
заведомо старался обойти вопрос своего алгоритма, потому что это не принципиально. я даже описание задачи упростил донельзя. теперь постараюсь ответить на ваш вопрос.
"При записи документов, потенциально влияющих на изменение статусов и показателей контрагента, ...."
у меня задействован еще один регистр сведений, называемый условно говоря "Список контрагентов, участвующих в системе бонусов", в которых фиксируются все изменения ключевых параметров: дата первой сделки, дата последней сделки, и т.д.
Поэтому, кроме регистра бухгалтерии Хозрасчетный "обеспечителем" информации 2011-го года в 2012-ом году стал вышеупомянутый регистр сведений. Он же до определенного момента использовался в "большом" запросе.
23. Rustig 1416 29.07.13 16:29 Сейчас в теме
(22) в новом алгоритме получилось так, что теперь при записи документа перезаписывается регистр сведений "Список контрагентов,....", а при перезаписи этого регистра контрагент попадает в регистр "Требуется переопределить статусы"...
то есть я добавил малость к старому механизму - при Записи регистра сведений "Список контрагентов,..." теперь происходит запись в дополнительный регистр "Требуется переопределить..."
24. hogik 432 29.07.13 16:58 Сейчас в теме
(23)
"при перезаписи этого регистра контрагент попадает в регистр"(с)
Рустем (Rustig).
А использовать временное множество (массив, список, рабочая таблица) строк содержания "дополнительного регистра" формируемого первым запросом/алгоритмом по регистру "Список контрагентов,...." в ОТЧЕТЕ для дальнейшей обработки другим запросом/алгоритмом - не получается?
25. Rustig 1416 29.07.13 17:16 Сейчас в теме
(24) ну что вы, :), конечно получается :) я же не об этом

вы обратили внимание на конструкцию в запросе из примера (9) ?

если кратко говорить, то суть моих изменений не в том, что перестал использовать временное хранилище из (24), а в том, что я разгрузил свой большой запрос от конструкций, подобных в примере (9).
26. hogik 432 29.07.13 17:46 Сейчас в теме
(25)
"разгрузил свой большой запрос от конструкций, подобных"(с)
Рустем (Rustig).
Про это написано в (12) сообщении. Последнее предложение.
А про выбранный Вами способ решения проблемы "больших" запросов написал Вам в первом сообщении (см. в личке). Еще до начала обсуждения в открытой печати. :-)
19. Rustig 1416 29.07.13 11:55 Сейчас в теме
(11) может быть я вас услышал? попробую пояснить ситуацию другими словами. вы спрашиваете:
Каким алгоритмом формируется "регистр сведений ТребуетсяПереопределитьСтатусы" на начальном этапе внедрения, если база данных уже находится в эксплуатации

по схеме на рис. 3 видно, что регистр бухгалтерии - "базовый". Это значит, что внедрять схему использования регистров сведений мы можем в любой момент эксплуатации системы. То есть, если у вас акцент в вопросе ставится на разделении во времении, то я говорю, что это неважно для нас.
20. Rustig 1416 29.07.13 13:06 Сейчас в теме
(11) по вашему комментарию мысли приходят разные и не сразу :)
Проектирование схемы базы данных "плясками от отчета"

Сейчас я хотел бы добавить, что добавление вспомогательных регистров не обязательно должно идти от необходимости создавать дополнительные отчеты. Просто в моем случае, это совпало.
В целом же необходимость создавать и использовать вспомогательные регистры для хранения промежуточной информации должно идти "от задачи", "от баланса, что использовать": запросы для динамического получения показателей или регистры для статического получения информации.
может быть вы об этом спрашивали? я правильно вас понимаю?
14. katya0702 28.07.13 22:49 Сейчас в теме
15. musatov1c.ru 29.07.13 07:19 Сейчас в теме
Интересно. У меня похоже есть заказ на похожую задачу. Обязательно опробую ваш метод :) Спасибо.
16. DoctorRoza 29.07.13 08:45 Сейчас в теме
ЗУП, в плане, крутых запросов - эталон в ТК! Хотя предложенный подход неявно, но реализован в УПП. Посмотрите, например, сколько движений делает документ Принятие ОС! :) Одних РС там 25 штук (1.2.21.1)! Каково, а!? :) Отмечу, что в предложенном подходе есть и небольшая мина, что, при смене программиста, его сменщик может не уловить идею и наиндусить!
fomix; u_n_k_n_o_w_n; Rustig; +3 Ответить
27. Ish_2 1052 30.07.13 16:14 Сейчас в теме
Рустем , правильно назвать тему "Я придумал костыль к типовой..".
Дескать , извернулся в данной конкретной ситуации, потому что другого пути не нашел.
"Затычка" она и есть "затычка". Не судите строго.
При таких разьяснениях не было бы недоуменных реплик про "пляски от отчета".

Если же ты предлагаешь свой подход в качестве "типового" приема в разработке , проектировании БД - мне очень жаль.
fomix; hogik; +2 Ответить
28. zfilin 2158 30.07.13 17:06 Сейчас в теме
(27) Ish_2, Скажите, а чем на ваш взгляд плох такой подход в качестве "типового" приема в разработке, проектировании БД?
29. Ish_2 1052 30.07.13 17:32 Сейчас в теме
(28) Суть приема Рустема - создание вспомогательных , дополнительных процедур и стуктур хранения информации для вывода отчета , непредусмотренного в типовой конфигурации.
Вполне возможно , что такой прием оправдан : деваться некуда , структура БД уже задана разработчиками 1с.

А вот если мы с нуля проектируем БД и априорно определена необходимость вывода вышеуказанного отчета ,то тогда применение приема Рустема с регламентными заданиями , пересчетами статусов для всего лишь вывода отчета смотрится избыточно и даже диковато.
30. Rustig 1416 30.07.13 17:43 Сейчас в теме
(29) Свершилось чудо! я наконец-то вас услышал! :)
А вот если мы с нуля проектируем БД и априорно определена необходимость вывода вышеуказанного отчета ,то тогда применение приема Рустема с регламентными заданиями , пересчетами статусов для всего лишь вывода отчета смотрится избыточно и даже диковато.

согласен с вами! я даже уже подумываю а не переписать ли конфу? только уже использовать регистры накопления и регистры сведений для хранения первичной информации вместо регистра бухгалтерии... полагаю, что ничего не стоит пересмотреть структуру БД и алгоритмы даже для базы, находящейся в эксплуатации.
31. hogik 432 30.07.13 17:50 Сейчас в теме
(30)
"для хранения первичной информации"(с)
Рустем (Rustig).
Как это согласуется с Вашей технологией - "хранить и создавать вторичную ;-) информацию"?
33. Rustig 1416 30.07.13 18:05 Сейчас в теме
(31) не знаю как согласуется :)
в описанном в статье подходе для наполнения регистра сведений я использую итоговые остатки бухгалтерского регистра.
если проектировать БД с нуля, то такой подход кажется не очевидным, и потому "диковатым". я наверное первым описал такой дикий подход. очевидным был бы подход создать регистры накопления как в УТ, которые будут накапливать информацию о взаиморасчетах с контрагентами, по своей сути повторяя те же бухгалтерские итоги в БП. При условии, что базы обмениваются документами.
35. hogik 432 30.07.13 18:18 Сейчас в теме
(33)
"создать регистры накопления ... которые будут накапливать информацию о взаиморасчетах с контрагентами"(с)
Рустем (Rustig).
У регистров есть еще одно (более значимое) назначение кроме как накапливать. ;-)
Вот мое мнение простым языком:
"... регистр можно "обозвать" общим составным индексом (в терминах СУБД) для множества иерархических структур (документов)."(с) http://infostart.ru/public/94437/
32. Rustig 1416 30.07.13 17:57 Сейчас в теме
(29) все же если вернуться к теме больших запросов... получается так, что на этапе проектирования сразу не видно какие регистры сведений и накоплений использовать при наличии регистров бухгалтерии и регистров расчетов. ведь кажется что последние регистры решат многие учетные проблемы. Далее система запускается в эксплуатацию, пишутся большие запросы, но уже ни у кого нет ресурсов переиначить структуру БД для упрощения (оптимизации) запросов. проблема не решается, а только усугубляется с изменением законодательства. пока мне так кажется ситуация. и еще мне кажется, почему бы не использовать встроенные механизмы получения итоговых остатков по регистру бухгалтерии и регистру расчетов (по сути уже разработанные, бери и пользуйся, как говорится)? Ведь если подумать только, что для получения аналогичных итоговых остатков, надо будет прописывать механизмы с использованием регистров накоплений - то объем решения задачи увеличивается десятикратно. как вы думаете? я пока простого решения не вижу
34. Ish_2 1052 30.07.13 18:10 Сейчас в теме
(32) Эге.. Да ты всерьез.
Я ведь прочитал тему наискосок и привел суждения (27),(29) навскидку.
От более подробного обсуждения воздержусь. Здесь важны детали (скорее всего дьявольские).
36. Rustig 1416 30.07.13 20:32 Сейчас в теме
(29) продолжая тему "диких" штучек, зацените http://infostart.ru/public/196028/
:) мне очень понравилось :)
37. Ish_2 1052 30.07.13 23:28 Сейчас в теме
(36) "Прогресс-бар" - слово смешное, согласен.
А еше - где там смеяться ?
39. dandykry 5 15.11.17 15:41 Сейчас в теме
(36) Такой механизм используют и разработчики ЗУП 3.1

Когда пишутся записи в КадроваяИсторияСотрудников, заполняется КадроваяИсторияСотрудниковИнтервальный, который используется потом во многих отчетах

ПлановыеНачисленияИнтервальный, ПлановыеАвансыИнтервальный и пр.

Тот же пример с регистром ТекущиеКадровыеДанныеСотрудников. Чтобы не получать через десяток запросов текущие показатели для вывода в список сотрудников, используется этот регистр.

ТекущаяТарифнаяСтавкаСотрудников и др.

Где-то на партнерском встречал упоминание от представителя 1с о "вспомогательных данных"
40. Rustig 1416 16.11.17 09:44 Сейчас в теме
(39) на дворе 2017 год - пора уже во всех программах применять такой подход.
Добавлю, что есть еще один "ход конем", который я не встречаю в программах:
использование в базах двух регистров сведений - связанных с одной функциональностью - один делается непериодическим , второй с теми же измерениями и ресурсами - но периодический. Пользователю в интерфейс выносим для работы с текущими данными первый регистр сведений, второй регистр сведений является "служебным" и используется для хранения истории изменения сведений.
В чем отличие - сейчас во всех программах подход един - используется для установки новых сведений периодический регистр - для пользователя измерение "Период" как такой не нужен - ему главное видеть текущее значение или установить новое. Если нужно видеть историю, то это "другая кнопка" должна быть и/или другой отчет. Хотя видеть историю чаще нужно администраторам базы.
Удобство двух регистров заключается в том, что программировать функциональность первого непериодического регистра сведений гораздо легче, вывести на экран для пользователя удобнее как для самого пользователя, так и для разработчика. Тут такое дело, что пока не столкнетесь с этой задачей, не поверите на слово...
41. KapasMordorov 429 16.11.17 10:41 Сейчас в теме
(40)
Работа "только оперативно" сильно усложнит алгоритмы, которые должны будут учитывать многократное сторно вместо изменения одного движения.
Поэтому работа задним числом и перепроведение - такая текущая ситуация устраивает большинство.
42. Rustig 1416 16.11.17 15:08 Сейчас в теме
(41) какую проблему вы пытаетесь решить своим перепроведением?

я изложил подход "как уменьшить и ускорить сложный запрос - используя вспомогательные регистры"
43. KapasMordorov 429 16.11.17 15:29 Сейчас в теме
(42)
Я? Ничего не пытаюсь, у меня нет проблем.
Добавлю, что есть еще один "ход конем", который я не встречаю в программах:
использование в базах двух регистров сведений - связанных с одной функциональностью - один делается непериодическим , второй с теми же измерениями и ресурсами - но периодический. Пользователю в интерфейс выносим для работы с текущими данными первый регистр сведений, второй регистр сведений является "служебным" и используется для хранения истории изменения сведений.

Вы изобрели СрезПоследних.
38. rayastar 65 09.01.14 14:31 Сейчас в теме
Вывод статьи я сделал в пользу того, что
первое - надо идти от отчета
второе - проявить творчество и подготовить исходные данные(создать вспомогательные регистры)
На самом деле, решение вспомогательных регистров лежит на поверхности, но пока не увидишь на примере - не поверишь :)
DarkAn; Rustig; +2 Ответить
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Ведущий программист 1С
Санкт-Петербург
зарплата от 130 000 руб.
Полный день

Специалист 1 категории (Программист 1С ФЗД)
Фрязино
зарплата от 110 000 руб.
Полный день

Специалист 1 категории (Программист 1С)
Фрязино
зарплата от 110 000 руб.
Полный день

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Специалист 1 категории (Методист-аналитик 1С)
Фрязино
зарплата от 100 000 руб.
Полный день