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

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

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

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

Вознаграждение за ответ
Показать полностью
Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Арчибальд 2710 26.07.13 10:24 Сейчас в теме
2. zfilin 2150 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 1373 29.07.13 10:35 Сейчас в теме
(12)
сделали те же самые промежуточные расчеты, разбив простыни запросов на мелкие и упорядочив это все в дополнительные функции


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

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

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

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

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


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

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

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

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


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

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

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

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

по схеме на рис. 3 видно, что регистр бухгалтерии - "базовый". Это значит, что внедрять схему использования регистров сведений мы можем в любой момент эксплуатации системы. То есть, если у вас акцент в вопросе ставится на разделении во времении, то я говорю, что это неважно для нас.
20. Rustig 1373 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 1049 30.07.13 16:14 Сейчас в теме
Рустем , правильно назвать тему "Я придумал костыль к типовой..".
Дескать , извернулся в данной конкретной ситуации, потому что другого пути не нашел.
"Затычка" она и есть "затычка". Не судите строго.
При таких разьяснениях не было бы недоуменных реплик про "пляски от отчета".

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

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

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

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

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

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

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

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

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

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

Вакансии

Программист 1С
Новосибирск
зарплата от 30 000 руб.
Временный (на проект)

Программист 1С
Москва
зарплата от 100 000 руб. до 150 000 руб.
Полный день

Специалист техподдержки 1С
Воронеж
зарплата от 30 000 руб. до 40 000 руб.
Полный день

Программист 1С
Воронеж
зарплата от 120 000 руб. до 200 000 руб.
Полный день

Студент (стажер) 1С
Воронеж
зарплата от 20 000 руб. до 30 000 руб.
Полный день