"Блок — простое механическое устройство, позволяющее регулировать силу.Подвижный блок предназначен для изменения величины прилагаемых усилий:для подъёма груза потребуется сила вдвое меньше, чем вес груза.При этом груз пройдёт расстояние, вдвое меньшее пройденного точкой приложения силы."
Часть 1. Вводная
Приемы и инструменты разбора и отладки больших запросов до сих пор (на момент 2024 г.) актуальны, только ведь все понимают, что сопровождать, изменять, дорабатывать такие сложные запросы никому не хочется — лично я не прихожу в восторг от очередного задания разобраться в запросе — одно уныние от таких запросов: усложнять запросы можно до бесконечности. А выигрыш какой?!
Основная проблема (и потеря времени) происходит тогда, когда надо быстро понять (прочесть) запрос, затем отладить его в консоли запросов со всеми текущими параметрами — понять для чего он был создан, почему именно такие связи между полями таблиц, где тот ключевой показатель, который надо изменить?
Я уверен, что временные виртуальные таблицы нужны, но не уверен, что нагромождать конфигурации большими кусочными запросами — это единственно правильный способ решить ту или иную задачу. Почему я убежден, что есть другой способ конфигурировать базы, потому что в свое время, разрабатывая конфигурацию, пошел по самому простому пути — для получения определенных данных стал формировать большие запросы. Получение данных с каждым годом замедлялось в разы — терпение лопнуло, когда я сформировал итоговый отчет за 8 часов.
В результате я пошел от задачи и придумал механизм хранения промежуточных показателей в таблицах базы данных. Удобство заключалось еще и в том, что я мог в любой момент через пользовательский режим посмотреть регистры с отбором по нужным мне измерениям и провести визуальный анализ на предмет корректного расчета промежуточных сведений. Спустя год я описал это в текущей статье.
Почему до сих пор это не стало повсеместным? — думаю, потому что способ "именно так решать задачи" до сих пор не популярен: очевиднее написать большой и сложный запрос.
Ниже будет рассмотрена реальная задача с немного измененной первоначальной постановкой, но в целом концепция решения сохранила свою изначальную идею. Извиняюсь заранее за сложность слога: описать идею проще не получилось. Поехали!
…Однажды я столкнулся с подобной проблемой, когда разрабатывал отчет для организации, ведущей учет задолженностей своих контрагентов в разрезе полугодий. Начисление и оплата регистрируется в регистре бухгалтерии по субконто1 – контрагенту и по субконто2 — условно назову его, период: за первое полугодие, за второе полугодие. Сложность учета заключалась в одновременном учете нескольких показателей (даты первой сделки, даты последней сделки, разделения оплат по полугодиям) и влиянии оплат предыдущих периодов на задолженность текущего периода. Не вдаваясь в детали учета, условно напишу так: от даты первой сделки и даты последней сделки зависело, за какой период должен оплатить контрагент. Выставление счетов производится каждое полугодие с учетом уже оплаченной суммы за предыдущие периоды (предыдущие года, предыдущее полугодие).
Если воспользоваться запросом для получения всех взаимосвязей и взаимовлияний показателей, то получится «большой» запрос. В чем проблема «большого» запроса? Он подобен карточному домику: строится долго, а захочется поменять карту из середины строения – домик разрушится. На своем примере я покажу, как я изменил механизм учета и превратил «большой» запрос в «маленький», а дальнейшее сопровождение программы в сказку 1С-ника. 
Часть 2. Главная
Использование регистров накопления и регистров сведений как вспомогательных очевидно при разработке подсистем оперативного учета. «Очевидно» — при условии, что к этим регистрам можно обратиться за получением понятной конечному пользователю информации. Сразу проиллюстрирую на картинках схемы использования механизмов 1С – вариант первый на рис. 1.
Рис. 1. Простая схема использования механизмов 1С
В данном случае в качестве регистра может быть использован любой регистр: регистр сведений, регистр накоплений, регистр бухгалтерии или регистр расчета. Не хочу углубляться в другую суть вопроса, что, мол, любая таблица подойдет для хранения промежуточной информации, или отчет и вовсе можно строить сразу на документах. Подразумеваю главным образом то, что при создании отчетов используются заложенные в регистрах собственные механизмы получения итогов.
Более сложную, но «понятную» схему использования механизмов демонстрирую на рис. 2.
Рис. 2. Более сложная схема использования механизмов 1С
Заметьте, что для получения отчета используются несколько регистров, напрямую связанных с документом, и регистры, напрямую не связанные с документом. Опять-таки в качестве регистра может быть использован любой регистр: регистр сведений, регистр накоплений, регистр бухгалтерии или регистр расчета.
Вернусь к вопросу «очевидности» использования вспомогательных регистров… Не так очевидно (!) их использование как таблицы хранения промежуточной, напрямую никому не нужной (без дополнительной обработки) информации. Для примера обратите внимание на механизм РАУЗ – на регистр сведений «Аналитика учета затрат». На мой взгляд, это первый случай использования промежуточных регистров такого рода – то есть для хранения промежуточной, напрямую никому не нужной (без дополнительной обработки) информации. Кто знает еще примеры, пишите, пожалуйста, в комментариях.
И совсем неочевидно использовать вспомогательные регистры совместно с регистрами бухгалтерии или регистрами расчета в таком варианте – рис. 3.
Рис. 3. Неочевидная схема использования механизмов 1С
*Скажу наперед, что структура вспомогательного регистра полностью повторила те разрезы и показатели, которые надо было отразить в отчете. То есть, я «плясал» от отчета: если надо было отразить такой показатель, как наличие «акта сверки», значит, в регистре возникало измерение Контрагент и возникал ресурс булева типа НаличиеАктаСверки. Если нужно было отразить такой показатель, как «частичная/полная оплата или совсем не оплатил», то в регистре возникал ресурс типа перечисление СтатусОплаты. То же самое коснулось и ресурса ДолгЗаПериод, который рассчитывался, как и все остальные показатели, в отдельно вынесенных алгоритмах.
**В дальнейшем я покажу и отчет, и структуру регистра – сейчас не суть.
***Я использовал непериодический регистр сведений. Так как не нужно было формировать отчет за предыдущие периоды, а нужно только на текущий момент. Но наличие дополнительного измерения Период не меняет принципа схемы, только лишь усложняет алгоритм расчета показателей, что не критично для решения нашей задачи – задачи избавиться от «большого» запроса.
Продолжу. В варианте 3 (рис. 3) мне надо было решить вопрос: в какой момент времени, и по какому событию промежуточная информация попадает во вспомогательный регистр? В вариантах 1 и 2 этот вопрос неочевиден, потому что информация попадает при проведении документа. (В случае регистров расчетов дополнительно используются служебные регистры Перерасчетов.)
Так вот, для решения этого вопроса я завел дополнительный регистр сведений ТребуетсяПереопределитьСтатусыКонтрагента и придумал такую схему – рис. 4.
Рис. 4. Расширение механизма учета
Поясню алгоритм схемы. При записи документов, потенциально влияющих на изменение статусов и показателей контрагента, данный контрагент попадает в регистр сведений ТребуетсяПереопределитьСтатусы. Перед завершением работы системы для пользователя с ролью ПравоНастройкиПрограммы вызывается процедура общего модуля ПереопределитьСтатусы, которая пробегает всех контрагентов из регистра ТребуетсяПереопределитьСтатусы и вызывает следующую процедуру общего модуля РассчитатьСтатусыПоКонтрагенту. В последней процедуре все показатели и статусы контрагента обретают новые значения и сохраняются в регистр СтатусыКонтрагента. Вызов процедуры переопределения статусов при формировании отчета происходит для всех пользователей.
Часть 3. Демонстрация
Ниже будут представлены иллюстрации и алгоритмы с минимум комментариев. Надеюсь все будет понятно.
Ниже представлен макет одного из отчета и структура вспомогательных регистров (рис. 5).
Рис. 5. Макет отчета и структура вспомогательных регистров
Ниже представлен список записей регистра сведений Статусы контрагентов: каждый контрагент выделен своим цветом. Список напоминает Олап-Куб – когда для одного и того же контрагента имеется ровно столько записей, сколько необходимо задействовать дополнительных измерений (в данном случае дополнительными измерениями выступают год и полугодие).
Рис. 6. Олап-куб записей вспомогательного регистра
Ниже представлен код вызова процедуры общего модуля ТребуетсяПереопределитьСтатусы.
Если Не Отказ И РольДоступна("ПравоНастройкиПрограммы") Тогда
Попытка
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| ТребуетсяПереопределитьСтатусы.Контрагент
|ИЗ
| РегистрСведений.ТребуетсяПереопределитьСтатусы КАК ТребуетсяПереопределитьСтатусы";
Результат = Запрос.Выполнить();
Если НЕ Результат.Пустой() Тогда
#Если Клиент Тогда
Сообщить("Не закрывайте окно и не выключайте компьютер: будет произведена регламентная процедура", СтатусСообщения.Информация);
#КонецЕсли
СписокКонтрагентов = Результат.Выгрузить().ВыгрузитьКолонку("Контрагент");
ДополнительныеФункции.ПереопределитьСтатусы(СписокКонтрагентов);
КонецЕсли;
Исключение
КонецПопытки;
КонецЕсли;
За кадром остается алгоритм расчета показателей, по сути влияния показателей друг на друга — в общем, алгоритм как алгоритм, в котором показатели определяются по различным условиям. Стоит только отметить три момента. Первый, для пояснения, о каких условиях идет речь. Например, контрагент оплатил за первое полугодие 2011 года сумму большую, чем полагалось. Тогда излишек должен распределиться (обратите внимание) на второе полугодие 2011 года, при условии, что за этот период оплаты не было. И т.д. анализ по всем периодам и условию, что контрагент в этом периоде еще осуществляет сделки (помните про дату первой сделки и дату последней сделки?)
И второй момент, что рассчитать показатели с помощью отдельно вынесенного алгоритма легче, чем рассчитывать показатели внутри "большого" запроса. "Легче" в плане разработки, прозрачности кода, отладки и дальнейшего расширения в рамках сопровождения. Выносить на обозрение "большой" запрос и конечный "малый" не буду, поскольку найдутся желающие оптимизировать "большой" запрос. Напишу только, что для получения отчета по всем показателям "малым" запросом использовано 66 строк запроса, оформленного конструктором запроса. А для получения отчета "большим" запросом я сначала произвел декомпозицию запроса, и для каждого отдельного показателя отчета использовал запрос в 100 строк. В таких запросах использовал пакетные запросы "ОтносящиесяКПервомуПолугодию", "ПолностьюОплатившиеЗаПолугодие", и т.д. и т.п. согласно условиям задачи.
Третий момент — ретроспектива или исторический — "большой" запрос себя оправдал на начальном этапе использования такого рода учета задолженностей контрагентов в разрезе полугодий. Но когда пришлось (через полгода) отразить в учете влияния переплат и долгов 2011 года на задолженности 2012 года, то схема "большого" запроса вдруг стала неповоротливой, настолько громоздской, что дала сбой. "Наращивание" и анализ показателей по полугодиям (с течением времени) с помощью "больших" запросов стали нетривиальными задачами. И наоборот, для добавления алгоритма по анализу показателей за 2013 год в процедуру общего модуля потребовалось 30 минут. Разве не сказка?
С пользой для клиентов, RustIG
Центр автоматизации, г. Казань
См. также:
Как эффективно использовать Инфостарт NEW!
Список реализаций + структура подчиненности + реестр документов SALE’1sm
Список заказов поставщикам + структура подчиненности SALE’1sm
Список заказов покупателей + структура подчиненности SALE’1sm
Договоры для 1с-ника ТОП-скачиваний
Сетка расписания (Планировщик) нестанДАрт
Два механизма, которые ускорили работу бухгалтеров в 1С нестанДАрт
Расчет банковских (рабочих) дней нестанДАрт
Шаблоны кода в режиме 1С:Предприятие SALE’1sm
Доработка конфигурации Конвертация Данных
Планирование платежей. Прогнозирование прибылей и убытков
Ввод показателей план-факта БП 3.0 Know-how
Инвентаризация личного опыта Для новичков 1С
Большие запросы: взгляд на проблему нестанДАрт
Технология создания коммерческих разработок Know-how
Андроид-решение для создания заказов в 1С Know-how + нестанДАрт
Печать ценников с одной и двумя ценами 55х40, 100х60, 140х200
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Внятно. Понравилось.
О! Декомпозиция, модульность, изоляция кода!
Спасибо, это отлично. Концепцию третьей схемы беру на вооружение.
Где-то пару раз «бессознательно» я так и поступал, но не выделил так четко в «архитектурный шаблон». Теперь все стало на место.
Раздел 3 ПереопределитьСтатусывыполнять не при завершении работы, а регламентным заданием.
Всё хорошо за исключением момента, когда нужно переопределить статусы. Согласен с (3), на эту роль хорошо подойдут регламентные и фоновые задания.
Сам сейчас решаю похожие проблемы в нашей конфигурации. Пришлось даже написать обработку, в которой строится дерево зависимостей временных таблиц запроса.
(3) Да, как сказать. Тут без пользователей и окружения наверняка сказать нельзя, когда именно следует обновлять эти данные. Если отчет не нужен чаще, например, чем раз в месяц и пользователь готов ждать, то нет особого смысла тратить ресурс на его периодический пересчет. Перед формированием — то, что нужно. Зачем нужно пересчитывать при завершении работы? Думаю, это надо спросить у уважаемого Рустема.
Мое предположение такое:
1. Все-таки пересчитывать регистры не только перед формированием, а еще когда-нибудь, чтобы пересчет перед формированием не был запредельно долгим, в случае, когда отчетом долго не пользовались.
2. Вот это «когда-нибудь» вешать на событие завершения работы для того, чтобы решение проще работало в файловом варианте, где для выполнения регламентных нужен пользователь «робот». А так можно обойтись без него.
Рустем, пролейте свет на вопрос. Зачем именно перед завершением, а не регламентом раз в сутки, например?
А вообще это мелочи. Идея хорошоа. Вот это главное.
(5) 🙂
удивительно! вы все верно написали.
Нифига не понял… Смысл в чем..? в том, что структура (вспомогательных) регистров проектировалась «от нужд отчета»..? Не уловил связь изложенного подхода с декомпозицией большого запроса…
???
(8) 🙂 Вспомогательные регистры служат для хранения промежуточно-рассчитанной информации. Структура хранения информации не должна совпадать с конечными макетами различных отчетов. Но многие отчеты могут использовать одну и ту же информацию о показателях, статусах — которые как раз и нужно хранить в вспомогательных регистрах.
…чтобы не плодить громоздских запросов, которые с избытком напичканы конструкциями (пример из ЗУП)
Показать
Хорошая схема, за исключением идеи расчета при завершении работы пользователя. С регламентниками оно как-то поинтереснее выглядит )
(0)
Рустем (Rustig).
Плюс под публикацию поставил. Однако, категорически не согласен с предлагаемым способом борьбы с «большими» запросами путем переноса проблем запроса в сложность схемы базы данных. Проектирование схемы базы данных «плясками от отчета» — это пляски на поминках информационной системы.
И первый 😉 вопрос к Вам:
Каким алгоритмом формируется «регистр сведений ТребуетсяПереопределитьСтатусы» на начальном этапе внедрения, если база данных уже находится в эксплуатации?
(2) zfilin,
Вы что, до этого не программировали?
(9)
Было бы все намного проще, если бы никто не развивал «концепции 1С», а просто сделали те же самые промежуточные расчеты, разбив простыни запросов на мелкие и упорядочив это все в дополнительные функции.
(11) hogik,
Я больше склоняюсь к мнению, что подобное больше является умствованием ради процесса, а не результата, хотя в 1С это и поощряется во всех проявлениях.
Интересно…
Интересно. У меня похоже есть заказ на похожую задачу. Обязательно опробую ваш метод 🙂 Спасибо.
ЗУП, в плане, крутых запросов — эталон в ТК! Хотя предложенный подход неявно, но реализован в УПП. Посмотрите, например, сколько движений делает документ Принятие ОС! 🙂 Одних РС там 25 штук (1.2.21.1)! Каково, а!? 🙂 Отмечу, что в предложенном подходе есть и небольшая мина, что, при смене программиста, его сменщик может не уловить идею и наиндусить!
(12)
🙂 спасибо за комментарий, надеюсь вашу рекомендацию услышат 1С-ники — разработчики типовых конфигураций.
что касается меня, то по возможности я так и делаю в своих задачах — разбиваю потенциально большой запрос на мелкие. Причина проста — я не силен в больших запросах, и быстрее набросать мелкие запросы.
Заметил две особенности:
1) скорость обработки информации увеличивается. Поэтому в тех задачах, где не критична скорость обработки данных, метод остается
2) в мелких запросах начинают повторяться пакетные запросы (временные таблицы), и для внесения совсем незначительного функционала уже требуется значительное время — проще говоря, одно и тоже приходится изменять в разных местах. Что можно было изменить за 5 минут — приходится изменять 40 минут, а то и больше, вспоминая через полгода, что там напрограммировано
(11) 🙂 спасибо за обсуждение
можно искать золотую середину, я ее нашел в своей задаче. мы едины в одном, что проблема «больших» запросов не надумана. правда? я правильно вас понимаю?
Спасибо, уже успел понять, что я не на том сделал акцент. 🙁
а вообще всю жизнь так руководствуюсь, что структура регистров накоплений должна прежде всего отвечать на вопрос «что в итоге мы должны получить?» Чтобы понять, надо ли нам применять оборотный регистр или регистр остатков. Зачастую один и тот же документ может делать записи в два разных похожих регистра накопления, отличия механизмов в том, что оба регистра — заполненные одними и теми же данными — будут использоваться в разных отчетах. Регистры могут отличаться даже не признаком, а одним измерением. Для целей учета и вывода в разные отчеты такой подход имеет право на существование. Эту идею почерпнул из книги Радченко и использую уже столько сколько программирую (5 лет).
Каким алгоритмом формируется «регистр сведений ТребуетсяПереопределитьСтатусы» на начальном этапе внедрения, если база данных уже находится в эксплуатации?
Если честно, не понял вопроса. База в эксплуатации, используется вовсю регистр бухгалтерии Хозрасчетный
Надо получить из него информацию о задолженности. На самом деле регистр не предусмотрен для решения таких задач, когда одни субконто сильно завязаны на других, и поэтому в бухгалтерских остатках надо учесть это влияние. Приходится писать запросы такого порядка, как в примере (9)
Такого рода запросы я разгрузил — вывел расчет в алгоритмы общих модулей, сохранил результаты расчетов в регистре сведений. Дальше использую показатели из регистра сведений. В моем случае получилось, что структура регистра выстраивалась согласно тем показателям, которые надо было получить в отчете. Также в результате получилось, что по каждому контрагенту приходится хранить информацию по всем разрезам — сам заранее не ожидал такого — описал в статье что будет некое подобие олап-куба. Хотя олап-куб и так используется вовсю в конфигурациях, когда мы отвечаем на вопрос «в разрезе каких измерений мы хотим получать отчетную информацию?»
(11) может быть я вас услышал? попробую пояснить ситуацию другими словами. вы спрашиваете:
по схеме на рис. 3 видно, что регистр бухгалтерии — «базовый». Это значит, что внедрять схему использования регистров сведений мы можем в любой момент эксплуатации системы. То есть, если у вас акцент в вопросе ставится на разделении во времении, то я говорю, что это неважно для нас.
(11) по вашему комментарию мысли приходят разные и не сразу 🙂
Сейчас я хотел бы добавить, что добавление вспомогательных регистров не обязательно должно идти от необходимости создавать дополнительные отчеты. Просто в моем случае, это совпало.
В целом же необходимость создавать и использовать вспомогательные регистры для хранения промежуточной информации должно идти «от задачи», «от баланса, что использовать»: запросы для динамического получения показателей или регистры для статического получения информации.
может быть вы об этом спрашивали? я правильно вас понимаю?
(18)
«не понял вопроса.»(с)
Рустем (Rustig).
А может я не понял Вашего алгоритма? 😉
Вот тексты:
1) «При записи документов, … контрагент попадает в регистр сведений …»(с)
2) «… пришлось (через полгода) отразить в учете влияния переплат и долгов 2011 года на задолженности 2012 года»(с)
Кто и как обеспечил в 2012 году информацию 2011 года в регистре ТребуетсяПереопределитьСтатусы для контрагентов, которые НЕ попадали в регистр в 2011 году, т.к. регистра еще не было?
(21) ясно, спасибо вам, что так глубоко вникаете в вопрос. вы правы в том, что что-то я не дорассказываю. 🙂
заведомо старался обойти вопрос своего алгоритма, потому что это не принципиально. я даже описание задачи упростил донельзя. теперь постараюсь ответить на ваш вопрос.
«При записи документов, потенциально влияющих на изменение статусов и показателей контрагента, ….»
у меня задействован еще один регистр сведений, называемый условно говоря «Список контрагентов, участвующих в системе бонусов», в которых фиксируются все изменения ключевых параметров: дата первой сделки, дата последней сделки, и т.д.
Поэтому, кроме регистра бухгалтерии Хозрасчетный «обеспечителем» информации 2011-го года в 2012-ом году стал вышеупомянутый регистр сведений. Он же до определенного момента использовался в «большом» запросе.
(22) в новом алгоритме получилось так, что теперь при записи документа перезаписывается регистр сведений «Список контрагентов,….», а при перезаписи этого регистра контрагент попадает в регистр «Требуется переопределить статусы»…
то есть я добавил малость к старому механизму — при Записи регистра сведений «Список контрагентов,…» теперь происходит запись в дополнительный регистр «Требуется переопределить…»
(23)
«при перезаписи этого регистра контрагент попадает в регистр»(с)
Рустем (Rustig).
А использовать временное множество (массив, список, рабочая таблица) строк содержания «дополнительного регистра» формируемого первым запросом/алгоритмом по регистру «Список контрагентов,….» в ОТЧЕТЕ для дальнейшей обработки другим запросом/алгоритмом — не получается?
(24) ну что вы, :), конечно получается 🙂 я же не об этом
вы обратили внимание на конструкцию в запросе из примера (9) ?
если кратко говорить, то суть моих изменений не в том, что перестал использовать временное хранилище из (24), а в том, что я разгрузил свой большой запрос от конструкций, подобных в примере (9).
(25)
«разгрузил свой большой запрос от конструкций, подобных»(с)
Рустем (Rustig).
Про это написано в (12) сообщении. Последнее предложение.
А про выбранный Вами способ решения проблемы «больших» запросов написал Вам в первом сообщении (см. в личке). Еще до начала обсуждения в открытой печати. 🙂
Рустем , правильно назвать тему «Я придумал костыль к типовой..».
Дескать , извернулся в данной конкретной ситуации, потому что другого пути не нашел.
«Затычка» она и есть «затычка». Не судите строго.
При таких разьяснениях не было бы недоуменных реплик про «пляски от отчета».
Если же ты предлагаешь свой подход в качестве «типового» приема в разработке , проектировании БД — мне очень жаль.
(27) Ish_2, Скажите, а чем на ваш взгляд плох такой подход в качестве «типового» приема в разработке, проектировании БД?
(28) Суть приема Рустема — создание вспомогательных , дополнительных процедур и стуктур хранения информации для вывода отчета , непредусмотренного в типовой конфигурации.
Вполне возможно , что такой прием оправдан : деваться некуда , структура БД уже задана разработчиками 1с.
А вот если мы с нуля проектируем БД и априорно определена необходимость вывода вышеуказанного отчета ,то тогда применение приема Рустема с регламентными заданиями , пересчетами статусов для всего лишь вывода отчета смотрится избыточно и даже диковато.
(29) Свершилось чудо! я наконец-то вас услышал! 🙂
согласен с вами! я даже уже подумываю а не переписать ли конфу? только уже использовать регистры накопления и регистры сведений для хранения первичной информации вместо регистра бухгалтерии… полагаю, что ничего не стоит пересмотреть структуру БД и алгоритмы даже для базы, находящейся в эксплуатации.
(30)
«для хранения первичной информации»(с)
Рустем (Rustig).
Как это согласуется с Вашей технологией — «хранить и создавать вторичную 😉 информацию»?
(29) все же если вернуться к теме больших запросов… получается так, что на этапе проектирования сразу не видно какие регистры сведений и накоплений использовать при наличии регистров бухгалтерии и регистров расчетов. ведь кажется что последние регистры решат многие учетные проблемы. Далее система запускается в эксплуатацию, пишутся большие запросы, но уже ни у кого нет ресурсов переиначить структуру БД для упрощения (оптимизации) запросов. проблема не решается, а только усугубляется с изменением законодательства. пока мне так кажется ситуация. и еще мне кажется, почему бы не использовать встроенные механизмы получения итоговых остатков по регистру бухгалтерии и регистру расчетов (по сути уже разработанные, бери и пользуйся, как говорится)? Ведь если подумать только, что для получения аналогичных итоговых остатков, надо будет прописывать механизмы с использованием регистров накоплений — то объем решения задачи увеличивается десятикратно. как вы думаете? я пока простого решения не вижу
(31) не знаю как согласуется 🙂
в описанном в статье подходе для наполнения регистра сведений я использую итоговые остатки бухгалтерского регистра.
если проектировать БД с нуля, то такой подход кажется не очевидным, и потому «диковатым». я наверное первым описал такой дикий подход. очевидным был бы подход создать регистры накопления как в УТ, которые будут накапливать информацию о взаиморасчетах с контрагентами, по своей сути повторяя те же бухгалтерские итоги в БП. При условии, что базы обмениваются документами.
(32) Эге.. Да ты всерьез.
Я ведь прочитал тему наискосок и привел суждения (27),(29) навскидку.
От более подробного обсуждения воздержусь. Здесь важны детали (скорее всего дьявольские).
(33)
«создать регистры накопления … которые будут накапливать информацию о взаиморасчетах с контрагентами»(с)
Рустем (Rustig).
У регистров есть еще одно (более значимое) назначение кроме как накапливать. 😉
Вот мое мнение простым языком:
«… регистр можно «обозвать» общим составным индексом (в терминах СУБД) для множества иерархических структур (документов).»(с)
(29) продолжая тему «диких» штучек, зацените
🙂 мне очень понравилось 🙂
(36) «Прогресс-бар» — слово смешное, согласен.
А еше — где там смеяться ?
Вывод статьи я сделал в пользу того, что
первое — надо идти от отчета
второе — проявить творчество и подготовить исходные данные(создать вспомогательные регистры)
На самом деле, решение вспомогательных регистров лежит на поверхности, но пока не увидишь на примере — не поверишь 🙂
(36) Такой механизм используют и разработчики ЗУП 3.1
Когда пишутся записи в КадроваяИсторияСотрудников, заполняется КадроваяИсторияСотрудниковИнтервальный, который используется потом во многих отчетах
ПлановыеНачисленияИнтервальный, ПлановыеАвансыИнтервальный и пр.
Тот же пример с регистром ТекущиеКадровыеДанныеСотрудников. Чтобы не получать через десяток запросов текущие показатели для вывода в список сотрудников, используется этот регистр.
ТекущаяТарифнаяСтавкаСотрудников и др.
Где-то на партнерском встречал упоминание от представителя 1с о «вспомогательных данных»
(39) на дворе 2017 год — пора уже во всех программах применять такой подход.
Добавлю, что есть еще один «ход конем», который я не встречаю в программах:
использование в базах двух регистров сведений — связанных с одной функциональностью — один делается непериодическим , второй с теми же измерениями и ресурсами — но периодический. Пользователю в интерфейс выносим для работы с текущими данными первый регистр сведений, второй регистр сведений является «служебным» и используется для хранения истории изменения сведений.
В чем отличие — сейчас во всех программах подход един — используется для установки новых сведений периодический регистр — для пользователя измерение «Период» как такой не нужен — ему главное видеть текущее значение или установить новое. Если нужно видеть историю, то это «другая кнопка» должна быть и/или другой отчет. Хотя видеть историю чаще нужно администраторам базы.
Удобство двух регистров заключается в том, что программировать функциональность первого непериодического регистра сведений гораздо легче, вывести на экран для пользователя удобнее как для самого пользователя, так и для разработчика. Тут такое дело, что пока не столкнетесь с этой задачей, не поверите на слово…
(40)
Работа «только оперативно» сильно усложнит алгоритмы, которые должны будут учитывать многократное сторно вместо изменения одного движения.
Поэтому работа задним числом и перепроведение — такая текущая ситуация устраивает большинство.
(41) какую проблему вы пытаетесь решить своим перепроведением?
я изложил подход «как уменьшить и ускорить сложный запрос — используя вспомогательные регистры»
(42)
Я? Ничего не пытаюсь, у меня нет проблем.
использование в базах двух регистров сведений — связанных с одной функциональностью — один делается непериодическим , второй с теми же измерениями и ресурсами — но периодический. Пользователю в интерфейс выносим для работы с текущими данными первый регистр сведений, второй регистр сведений является «служебным» и используется для хранения истории изменения сведений.
Вы изобрели СрезПоследних.