"Расширяемые" регистры и табличные части

15.05.12

Разработка - Математика и алгоритмы

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

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

Целью данной заметки является краткое описание концепции, позволяющей создавать и поддерживать более широкие возможности – расширяемые регистры и табличные части. Реализация данных механизмов представляется оптимальной в виде подсистемы с высокой степенью портируемости и универсальности. Опишем объекты, входящие в подсистему, применив взятую для удобства нотацию имён. Нотация имён имеет рекомендательный характер.

План видов характеристик «Разрезы сочетаний». ПВХ описывает состав и типы данных для изменяемых функционалов, т.е., как и в классическом варианте, описывает «добавляемые» пользователем поля. Если в конфигурации есть несколько задач, решаемых описываемым способом, можно сделать ПВХ иерархическим. Реквизиты – на усмотрение разработчика. В зависимости от решаемых задач варьируются допустимые типы.

Справочник «Сочетания разрезов». Справочник собственно содержит конкретные данные всех изменяемых функционалов, значения «добавленных» пользователем полей. Рекомендуется делать его иерархическим с иерархией групп, что позволит повысить скорость работы с подмножествами его элементов через использование штатной механики платформы, но можно обойтись и без иерархии. Также можно задействовать связь по владельцу. Рекомендуется использовать представление в виде кода и сделать длину наименования нулевой. Если в конфигурации есть несколько задач, решаемых описанным способом, и по каждой прогнозируется рост объёмов данных, имеет смысл создавать отдельные справочники одинаковой структуры – это распараллелит нагрузку. Группа справочника может иметь реквизиты, ускоряющие её обнаружение и, через неё, работу с её элементами. Элемент справочника может не иметь шапочных реквизитов (это – на усмотрение разработчика), но обязательно должен иметь табличную часть «Состав сочетания», содержащую 2 реквизита: «Разрез» (ссылка на ПВХ «Разрезы сочетаний») и «ЗначениеРазреза» (характеристика ПВХ «Разрезы сочетаний»). Каждый элемент справочника содержит уникальное сочетание значений «ЗначенийРазрезов», таким образом, двух элементов с абсолютно идентичными табличными частями быть не должно. Это достигается функционалом общего модуля – поиском имеющихся сочетаний, и лежит на совести разработчика. Именно уникальность элементов принципиально важна.

Общий модуль «РаботаССочетаниями», с возможностью выполнения на сервере, где расположены нужные процедуры и функции. По сути можно предложить такие, как «НайтиСочетаниеРазрезов» и «СоздатьОбновитьСочетаниеРазрезов». Их аргументом будет таблица значений, аналогичная табличной части справочника «Сочетания разрезов», а их задачи будут заключаться в поиске имеющегося сочетания по указанному образцу и в создании либо обновлении имеющегося сочетания (ранее найденного по, возможно, другому набору значений разрезов). Очевидно, что для этого следует использовать характеристический механизм запросов с помощью СКД.

Примерный вид запроса для СКД:

ВЫБРАТЬ Сочетания.Ссылка КАК СочетаниеСсылка ИЗ Справочник.СочетанияРазрезов КАК Сочетания ГДЕ Сочетания.ПометкаУдаления = Ложь И Сочетания.Ссылка В ИЕРАРХИИ (&УслРодительскаяГруппа) // и любое другое условие, позволяющее ограничить объём выборки {ХАРАКТЕРИСТИКИ ТИП(Справочник.СочетанияРазрезов) ВИДЫХАРАКТЕРИСТИК (ВЫБРАТЬ ПВХРазрезыСочетаний.Ссылка КАК ПВХРазрез, ПВХРазрезыСочетаний.Наименование КАК ПВХНаименование, ПВХРазрезыСочетаний.ТипЗначения КАК ПВХТипЗначения ИЗ ПланВидовХарактеристик.РазрезыСочетаний КАК ПВХРазрезыСочетаний ГДЕ ПВХРазрезыСочетаний.ЭтоГруппа = Ложь) ПОЛЕКЛЮЧА ПВХРазрез ПОЛЕИМЕНИ ПВХНаименование ПОЛЕТИПАЗНАЧЕНИЯ ПВХТипЗначения ЗНАЧЕНИЯХАРАКТЕРИСТИК (ВЫБРАТЬ Состав.Ссылка КАК Сочетание, Состав.Разрез КАК Разрез, Состав.ЗначениеРазреза КАК ЗначениеРазреза ИЗ Справочник.СочетанияРазрезов.СоставСочетанияРазрезов КАК Состав И Состав.ПометкаУдаления = Ложь И Состав.Ссылка В ИЕРАРХИИ (&УслРодительскаяГруппа) // и любое другое условие, позволяющее ограничить объём выборки ) ПОЛЕОБЪЕКТА Сочетание ПОЛЕВИДА Разрез ПОЛЕЗНАЧЕНИЯ ЗначениеРазреза} 

За внешний вид запроса благодарю обработку Evg-Lylyk (хотя сделать переносы строк и вариант для не-управляемых форм было б невредно, ага)

Очевидно, что для поиска нужных сочетаний следует наложить условия на поля СКД, соблюдая их нотацию. Напомню, при наличии символов, недопустимых в именах системных полей, платформа выполняет неявное преобразование данных, переданных ей в ПОЛЕИМЕНИ, и следует соблюдать правила написания пути к данным в отборах СКД, т.е. нечто вида "СочетаниеСсылка.["+ПолеКакЕгоОбозвалаСКД+"]".

Собственно реализация может быть любой. Рассмотрим на примере регистра сведений с составом, управляемым пользователем. Предположим, нам нужен регистр сведений, хранящий отпускные цены, зависящие от заранее неизвестного набора значений, и состав этого набора непредсказуем. Так, пусть цена зависит от группы контрагентов и региона. Регистр будет иметь лишь одно обязательное измерение (остальное – на усмотрение разработчика), а именно «СочетаниеРазрезов», ссылку на справочник. Опустим интерфейсные ухищрения, заметим лишь, что для пользователя рабочая таблица регистра должна иметь привычный вид: колонки измерений, ресурсов и реквизитов, и что для организации такого интерфейса следует предпринять определённые усилия по написанию кода. Впрочем, можно лишь незначительно доработать форму списка, обеспечив прямой переход к просмотру/редактированию каждого элемента справочника.

Главное в работе с регистром то, что вместо статично заданных измерений пользователь имеет дело со строками табличных частей элементов справочника, являющегося измерением. Каждый элемент справочника уникален. При появлении нового сочетания значений создаётся новый элемент справочника. Таким образом, справочник содержит все имеющиеся варианты значений в их сочетаниях, и каждый набор сочетаний позволяет найти соответствующий элемент, а зная его, и запись в регистре. Изменения в составе разрезов могут и должны сказываться на составе табличных частей элементов справочника, но суть не изменится – единственным измерением будет сам этот справочник, хотя для пользователя он может быть сделан вообще «скрытым» чисто интерфейсными средствами или через RLS.

Аналогично, можно сделать табличную часть объекта, где одним из реквизитов будет ссылка на справочник «Сочетания разрезов». Тогда для пользователя состав данных этой табличной части будет столь широк, сколько разрезов фигурирует в табличных частях справочников, и опять-таки это будет в распоряжении пользователя.

В общем случае количество строк в табличных частях разных элементов справочника может быть совершенно разным, поэтому вопрос актуализации и синхронизации целиком ложится на разработчика. Так, если ранее практиковались 2 разреза («Группа контрагентов» и «Регион»), а позже пользователь ввёл разрез «Категория товара», то табличные части элементов справочника, созданные ранее, могут остаться неизменными, если реализация рабочих модулей будет это учитывать; в противном случае следует продумать дописывание в табличных частях строки с новым разрезом и пустым значением (по сути, ту же операцию, что делает платформа при добавлении измерения в регистр разработчиком). Аналогично следует не забыть обработку случаев изменения типа значений ПВХ или удаления элемента ПВХ.

На следующем этапе развития подсистемы можно ввести понятие шаблона, образца сочетания разрезов, и обеспечить наполнение табличных частей не любыми разрезами и их значениями, а только входящими в образец. Это позволит ещё оптимизировать работу с содержимым справочника. Можно при описании образца указывать, является ли значение того или иного разреза обязательным или нет, можно создать механику избирательного доступа к тем или иным значениям разрезов и т.д., вплоть до конструирования псевдо-OLAP систем, т.е. принципа управляемой многомерности, чему, возможно, будет посвящена следующая заметка.

 

См. также

Метод Дугласа-Пойкера для эффективного хранения метрик

Математика и алгоритмы Платформа 1C v8.2 Конфигурации 1cv8 Россия Абонемент ($m)

На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.

1 стартмани

30.01.2024    1715    stopa85    12    

33

Алгоритм симплекс-метода для решения задачи раскроя

Математика и алгоритмы Бесплатно (free)

Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.

19.10.2023    4319    user1959478    50    

34

Регулярные выражения на 1С

Математика и алгоритмы Инструментарий разработчика Платформа 1С v8.3 Мобильная платформа Россия Абонемент ($m)

Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.

1 стартмани

09.06.2023    7349    4    SpaceOfMyHead    17    

56

Модель распределения суммы по базе

Математика и алгоритмы Платформа 1С v8.3 Россия Абонемент ($m)

Обычно под распределением понимают определение сумм пропорционально коэффициентам. Предлагаю включить сюда также распределение по порядку (FIFO, LIFO) и повысить уровень размерности до 2-х. 1-ое означает, что распределение может быть не только пропорциональным, но и по порядку, а 2-ое - это вариант реализации матричного распределения: по строкам и столбцам. Возможно вас заинтересует также необычное решение этой задачи через создание DSL на базе реализации текучего интерфейса

1 стартмани

21.03.2022    7820    7    kalyaka    11    

44

Изменения формата файлов конфигурации (CF) в 8.3.16

Математика и алгоритмы Платформа 1С v8.3 Бесплатно (free)

Дополнение по формату файлов конфигурации (*.cf) в версии 8.3.16.

16.12.2021    4415    fishca    13    

36

Интересная задача на Yandex cup 2021

Математика и алгоритмы Бесплатно (free)

Мое решение задачи на Yandex cup 2021 (frontend). Лабиринт. JavaScript.

12.10.2021    8794    John_d    73    

46

Механизм анализа данных. Кластеризация.

Математика и алгоритмы Анализ учета Платформа 1С v8.3 Анализ и прогнозирование Бесплатно (free)

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

31.08.2021    7720    dusha0020    8    

70
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. fuxic 297 15.05.12 18:37 Сейчас в теме
Было бы неплохо увидеть базу с примером использования. Заранее благодарю, если поделитесь
2. Yashazz 4707 15.05.12 19:10 Сейчас в теме
(1) Есть мысль доделать нормальную подсистему, постараюсь выложить в ближайшие дни. Сейчас оно так лихо интегрировано, что придётся выкладывать всю конфу, а это мне низя.
Изложенная концепция успешно используется на практике уже год, поэтому и решил поделиться. Если что-то не подробно, постараюсь детализировать.
3. khaoos 239 16.05.12 06:51 Сейчас в теме
Идея замечательная. Конечно, реализацию в виде готовой подсистемы хотелось бы иметь. Как дела с производительностью?
4. Yashazz 4707 16.05.12 08:26 Сейчас в теме
(3) Если делать на большие объёмы один неиерархический справочник - дела с производительностью так себе. Если же предпринимать усилия по всякой оптимизации, то очень даже неплохо. Упомянутый запрос у меня на ста тысячах элементов отрабатывает за пару секунд, и это на файловой базе.
Реализацию ещё выдрать из конфы надо. :)
7. khaoos 239 16.05.12 09:25 Сейчас в теме
(4) Хорошо, подождем. А по производительности: есть ощущение, если вместо табличной части справочника сочетаний использовать вспомогательный регистр сведений с его возможностью кластерного индекса, то будет быстрее. Хотя если и так все хорошо, то ломать не стоит :)
5. AVVG 16.05.12 08:56 Сейчас в теме
Да если глянуть примерчик было бы очень здорово но смущает выборка всего из 100000 и уже не быстро а что такое 100000? Поэтому смотреть и тестить. Заранее спасибо
6. Yashazz 4707 16.05.12 09:18 Сейчас в теме
(5) Когда планируется большое количество разрезов, т.е. большое количество вариантов их сочетаний без повторений (порядок разрезов считаем неважным), то, конечно, будет и много больше ста тысяч. Сам тоже "буду посмотреть", как оно живёт на SQL, т.к., повторюсь, база файловая.

Тут ведь в чём гадость: СКД не позволяет нормально оптимизировать выборки внутри секции запроса характеристик. Ни временных таблиц, ничего, увы. Это считаю узким местом.
8. electronik 16.05.12 11:07 Сейчас в теме
Интересно интересно.Мое мнение нужно ето дело увидеть на практике. Автору за идею и за работу спасибо, ну и конечно заслуженое 5+++++
9. gaglo 16.05.12 13:48 Сейчас в теме
Идея - безусловно - многообещающщщая, поставил закладку, буду вдумчиво перечитывать, и если подсистема появится - будет вообще здорово!
ЗЫ Однако терминология... Прочитав "Разрезы сочетаний" ...... "Сочетания разрезов" - минут 15 не мог сосредоточиться -
это ж "План по валу" - "Вал по плану!"
10. Yashazz 4707 16.05.12 15:28 Сейчас в теме
(9) Согласен, вернее, конечно, формулировка "Сочетания конкретных значений разрезов". Но длинно.
12. vvr908 446 16.05.12 17:14 Сейчас в теме
(10) по смыслу чем-то напоминает ключи аналитики из РАУЗ. Может, так и назвать: ПВХДопАналитика и КлючиДопАналитики?
11. Kamikadze 46 16.05.12 17:14 Сейчас в теме
"Значениz разрезов" - чем не подходит такое название?
13. Yashazz 4707 16.05.12 18:23 Сейчас в теме
(13) Можно, только и "ДопАналитика" бывает разная. Вообще да, вопрос терминологии довольно остро стоит для этой задачи. Какие ещё есть предложения?
Я посмотрю, какие варианты, и когда буду выкладывать подсистему, уже сделаю в ней именно такую нотацию.
14. RustIG 1301 17.05.12 06:44 Сейчас в теме
(0) как концепция статья понравилась. напишите пожалуйста изначальную постановку задачи. думаю, что задачу возможно решить более "легковоспринимаемым" способом.
а на практике за счет увеличения взамосвязей объектов метаданных происходит усложнение разработки, доработки, отладки: к примеру, как в Комплексной конфигурации реализованы регистры РАУЗ? Через такой же расширяемый регистр. Только в измерениях справочник - ключ, являющийся комбинацией всех своих реквизитов, в реквизитах тоже справочники-ключи, являющиеся комбинациями своих реквизитов. Можно продолжить ряд...
А такое видели? Справочник содержит предопределенные макеты на СКД - по сути запросы к базе. Теперь для любого элемента этого справочника можно выбрать реквизит - какой конкретно способ (по сути запрос) будет использоваться при закрытии месяца. кто в курсе меня поправит...
Или кто-нибудь видел БГУ? Там тоже много интересного: в каждом документе определяется ЛокальнаяПеременная через название, тип этой переменной изменяется в зависимости от переданного названия. Или как определяется доступность реквизитов и значения по умолчанию для документов в БГУ? Через справочник ВидОперации - который является ключевым реквизитом в таких справочниках как РеквизитыДокументовПрочие, РеквизитыЕСПБУ. Кто в курсе меня поправит :)
Это все примеры того, как на базовые объекты конфигурации (нижний уровень) накладываются сложные для восприятия взаимосвязи (средний уровень), и получаются механизмы иного порядка (верхний уровень). И тогда с помощью таких пирамид решаются задачи уже другого порядка.
Мда, для разработчиков настоящая головоломка...
16. Yashazz 4707 17.05.12 10:21 Сейчас в теме
(14) про РАУЗ ничего не знаю, честно. А этой концепции, которую я описал в заметке, уж года четыре. Просто решил опубликовать наконец.
20. AlX0id 18.05.12 12:13 Сейчас в теме
(16)
У меня лично при виде подобной статьи в первую очередь возникает вопрос: в РАУЗе-то оптимизирована структура для уменьшения возможности конфликтов взаимоблокировок.. а как тут?

И - да, на порядок возрастает сложность доработок подобных систем, если они обоснованно необходимы, конечно.
17. samamoiloff 861 17.05.12 12:44 Сейчас в теме
(14)Занятно. Может статейку кто накрапает о подобных принципах? Думаю, будет популярна. Самому вскоре придется что-то придумывать на эту тему, было бы интересно иметь сведения из практики. А то лезут в голову всякие мысли иногда, типа "возможно ли внешнее регламентное задание..." :)
18. Yashazz 4707 17.05.12 18:53 Сейчас в теме
(14) Изначальной задачей был регистр сведений с неизвестным заранее набором измерений. Ровно то, что описано в примере. Возможность пользователя менять мерность и характер измерений регистра.
19. RustIG 1301 17.05.12 19:39 Сейчас в теме
(18) Это же постановка задачи на языке разработчика. А постановка задач на языке клиента есть? Все ли меня понимают, о чем я прошу? :)
21. Yashazz 4707 18.05.12 19:17 Сейчас в теме
(19) А на языке клиента ничего конкретного не было. Клиент сам не знал, от чего будут зависеть цены, и всё сводилось к обычному "сделайте, чтобы работало и мы могли сами поменять". Даже нормального ТЗ не состоялось.

(20) Возможно, скажу глупость, но - а какие тут могут быть взаимоблокировки? Это ведь справочник. чтение - есть чтение, без блокировки для изменения. Каждое действие происходит только с одним элементом, чистая объектная блокировка силами платформы. Или я не понял, о чём речь?

Насчёт возрастания сложности на порядок - не соглашусь. Если не дорабатывать сам механизм, а просто его юзать, то ничего особенного, сужу по своим коллегам.
15. ms200999 17.05.12 08:37 Сейчас в теме
Любопытно. Буду следить за развитием идеи.
22. Ksu 03.09.12 12:14 Сейчас в теме
Идея не плохая. У нас сейчас стоит та же задача. Поэтому очень интересно Ваше решение.
23. Yashazz 4707 06.09.12 13:42 Сейчас в теме
(22) Ни сил, ни времени выламывать подсистему из готовых решений, к сожалению, нет. Могу разве только совсем грубо "кусок выдрать".
24. Ksu 07.09.12 15:28 Сейчас в теме
Если не затруднит, то было бы здорово!
Оставьте свое сообщение