0. Yashazz 2884 14.05.12 18:41 Сейчас в теме

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

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

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

Комментарии
Избранное Подписка Сортировка: Древо
1. fuxic 292 15.05.12 18:37 Сейчас в теме
Было бы неплохо увидеть базу с примером использования. Заранее благодарю, если поделитесь
2. Yashazz 2884 15.05.12 19:10 Сейчас в теме
(1) Есть мысль доделать нормальную подсистему, постараюсь выложить в ближайшие дни. Сейчас оно так лихо интегрировано, что придётся выкладывать всю конфу, а это мне низя.
Изложенная концепция успешно используется на практике уже год, поэтому и решил поделиться. Если что-то не подробно, постараюсь детализировать.
3. khaoos 239 16.05.12 06:51 Сейчас в теме
Идея замечательная. Конечно, реализацию в виде готовой подсистемы хотелось бы иметь. Как дела с производительностью?
4. Yashazz 2884 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 2884 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 2884 16.05.12 15:28 Сейчас в теме
(9) Согласен, вернее, конечно, формулировка "Сочетания конкретных значений разрезов". Но длинно.
12. vvr908 397 16.05.12 17:14 Сейчас в теме
(10) по смыслу чем-то напоминает ключи аналитики из РАУЗ. Может, так и назвать: ПВХДопАналитика и КлючиДопАналитики?
11. Kamikadze 46 16.05.12 17:14 Сейчас в теме
"Значениz разрезов" - чем не подходит такое название?
13. Yashazz 2884 16.05.12 18:23 Сейчас в теме
(13) Можно, только и "ДопАналитика" бывает разная. Вообще да, вопрос терминологии довольно остро стоит для этой задачи. Какие ещё есть предложения?
Я посмотрю, какие варианты, и когда буду выкладывать подсистему, уже сделаю в ней именно такую нотацию.
14. Rustig 1205 17.05.12 06:44 Сейчас в теме
(0) как концепция статья понравилась. напишите пожалуйста изначальную постановку задачи. думаю, что задачу возможно решить более "легковоспринимаемым" способом.
а на практике за счет увеличения взамосвязей объектов метаданных происходит усложнение разработки, доработки, отладки: к примеру, как в Комплексной конфигурации реализованы регистры РАУЗ? Через такой же расширяемый регистр. Только в измерениях справочник - ключ, являющийся комбинацией всех своих реквизитов, в реквизитах тоже справочники-ключи, являющиеся комбинациями своих реквизитов. Можно продолжить ряд...
А такое видели? Справочник содержит предопределенные макеты на СКД - по сути запросы к базе. Теперь для любого элемента этого справочника можно выбрать реквизит - какой конкретно способ (по сути запрос) будет использоваться при закрытии месяца. кто в курсе меня поправит...
Или кто-нибудь видел БГУ? Там тоже много интересного: в каждом документе определяется ЛокальнаяПеременная через название, тип этой переменной изменяется в зависимости от переданного названия. Или как определяется доступность реквизитов и значения по умолчанию для документов в БГУ? Через справочник ВидОперации - который является ключевым реквизитом в таких справочниках как РеквизитыДокументовПрочие, РеквизитыЕСПБУ. Кто в курсе меня поправит :)
Это все примеры того, как на базовые объекты конфигурации (нижний уровень) накладываются сложные для восприятия взаимосвязи (средний уровень), и получаются механизмы иного порядка (верхний уровень). И тогда с помощью таких пирамид решаются задачи уже другого порядка.
Мда, для разработчиков настоящая головоломка...
16. Yashazz 2884 17.05.12 10:21 Сейчас в теме
(14) про РАУЗ ничего не знаю, честно. А этой концепции, которую я описал в заметке, уж года четыре. Просто решил опубликовать наконец.
20. AlX0id 18.05.12 12:13 Сейчас в теме
(16)
У меня лично при виде подобной статьи в первую очередь возникает вопрос: в РАУЗе-то оптимизирована структура для уменьшения возможности конфликтов взаимоблокировок.. а как тут?

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

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

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

Вакансии

Программист, аналитик, эксперт 1С
Санкт-Петербург
По совместительству

Технический лидер, архитектор 1С, руководитель проектов
Санкт-Петербург
зарплата от 150 000 руб.
Полный день

Ведущий 1С консультант по БГУ
Омск
зарплата от 50 000 руб. до 95 000 руб.
Полный день

Специалист внедрения и сопровождения 1С
Омск
зарплата от 25 000 руб. до 50 000 руб.
Полный день

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