Комментарии
Избранное
Подписка
Сортировка:
Древо
(1) Есть мысль доделать нормальную подсистему, постараюсь выложить в ближайшие дни. Сейчас оно так лихо интегрировано, что придётся выкладывать всю конфу, а это мне низя.
Изложенная концепция успешно используется на практике уже год, поэтому и решил поделиться. Если что-то не подробно, постараюсь детализировать.
Изложенная концепция успешно используется на практике уже год, поэтому и решил поделиться. Если что-то не подробно, постараюсь детализировать.
(3) Если делать на большие объёмы один неиерархический справочник - дела с производительностью так себе. Если же предпринимать усилия по всякой оптимизации, то очень даже неплохо. Упомянутый запрос у меня на ста тысячах элементов отрабатывает за пару секунд, и это на файловой базе.
Реализацию ещё выдрать из конфы надо. :)
Реализацию ещё выдрать из конфы надо. :)
(4) Хорошо, подождем. А по производительности: есть ощущение, если вместо табличной части справочника сочетаний использовать вспомогательный регистр сведений с его возможностью кластерного индекса, то будет быстрее. Хотя если и так все хорошо, то ломать не стоит :)
(5) Когда планируется большое количество разрезов, т.е. большое количество вариантов их сочетаний без повторений (порядок разрезов считаем неважным), то, конечно, будет и много больше ста тысяч. Сам тоже "буду посмотреть", как оно живёт на SQL, т.к., повторюсь, база файловая.
Тут ведь в чём гадость: СКД не позволяет нормально оптимизировать выборки внутри секции запроса характеристик. Ни временных таблиц, ничего, увы. Это считаю узким местом.
Тут ведь в чём гадость: СКД не позволяет нормально оптимизировать выборки внутри секции запроса характеристик. Ни временных таблиц, ничего, увы. Это считаю узким местом.
Идея - безусловно - многообещающщщая, поставил закладку, буду вдумчиво перечитывать, и если подсистема появится - будет вообще здорово!
ЗЫ Однако терминология... Прочитав "Разрезы сочетаний" ...... "Сочетания разрезов" - минут 15 не мог сосредоточиться -
это ж "План по валу" - "Вал по плану!"
ЗЫ Однако терминология... Прочитав "Разрезы сочетаний" ...... "Сочетания разрезов" - минут 15 не мог сосредоточиться -
это ж "План по валу" - "Вал по плану!"
(0) как концепция статья понравилась. напишите пожалуйста изначальную постановку задачи. думаю, что задачу возможно решить более "легковоспринимаемым" способом.
а на практике за счет увеличения взамосвязей объектов метаданных происходит усложнение разработки, доработки, отладки: к примеру, как в Комплексной конфигурации реализованы регистры РАУЗ? Через такой же расширяемый регистр. Только в измерениях справочник - ключ, являющийся комбинацией всех своих реквизитов, в реквизитах тоже справочники-ключи, являющиеся комбинациями своих реквизитов. Можно продолжить ряд...
А такое видели? Справочник содержит предопределенные макеты на СКД - по сути запросы к базе. Теперь для любого элемента этого справочника можно выбрать реквизит - какой конкретно способ (по сути запрос) будет использоваться при закрытии месяца. кто в курсе меня поправит...
Или кто-нибудь видел БГУ? Там тоже много интересного: в каждом документе определяется ЛокальнаяПеременная через название, тип этой переменной изменяется в зависимости от переданного названия. Или как определяется доступность реквизитов и значения по умолчанию для документов в БГУ? Через справочник ВидОперации - который является ключевым реквизитом в таких справочниках как РеквизитыДокументовПрочие, РеквизитыЕСПБУ. Кто в курсе меня поправит :)
Это все примеры того, как на базовые объекты конфигурации (нижний уровень) накладываются сложные для восприятия взаимосвязи (средний уровень), и получаются механизмы иного порядка (верхний уровень). И тогда с помощью таких пирамид решаются задачи уже другого порядка.
Мда, для разработчиков настоящая головоломка...
а на практике за счет увеличения взамосвязей объектов метаданных происходит усложнение разработки, доработки, отладки: к примеру, как в Комплексной конфигурации реализованы регистры РАУЗ? Через такой же расширяемый регистр. Только в измерениях справочник - ключ, являющийся комбинацией всех своих реквизитов, в реквизитах тоже справочники-ключи, являющиеся комбинациями своих реквизитов. Можно продолжить ряд...
А такое видели? Справочник содержит предопределенные макеты на СКД - по сути запросы к базе. Теперь для любого элемента этого справочника можно выбрать реквизит - какой конкретно способ (по сути запрос) будет использоваться при закрытии месяца. кто в курсе меня поправит...
Или кто-нибудь видел БГУ? Там тоже много интересного: в каждом документе определяется ЛокальнаяПеременная через название, тип этой переменной изменяется в зависимости от переданного названия. Или как определяется доступность реквизитов и значения по умолчанию для документов в БГУ? Через справочник ВидОперации - который является ключевым реквизитом в таких справочниках как РеквизитыДокументовПрочие, РеквизитыЕСПБУ. Кто в курсе меня поправит :)
Это все примеры того, как на базовые объекты конфигурации (нижний уровень) накладываются сложные для восприятия взаимосвязи (средний уровень), и получаются механизмы иного порядка (верхний уровень). И тогда с помощью таких пирамид решаются задачи уже другого порядка.
Мда, для разработчиков настоящая головоломка...
(16)
У меня лично при виде подобной статьи в первую очередь возникает вопрос: в РАУЗе-то оптимизирована структура для уменьшения возможности конфликтов взаимоблокировок.. а как тут?
И - да, на порядок возрастает сложность доработок подобных систем, если они обоснованно необходимы, конечно.
У меня лично при виде подобной статьи в первую очередь возникает вопрос: в РАУЗе-то оптимизирована структура для уменьшения возможности конфликтов взаимоблокировок.. а как тут?
И - да, на порядок возрастает сложность доработок подобных систем, если они обоснованно необходимы, конечно.
(14)Занятно. Может статейку кто накрапает о подобных принципах? Думаю, будет популярна. Самому вскоре придется что-то придумывать на эту тему, было бы интересно иметь сведения из практики. А то лезут в голову всякие мысли иногда, типа "возможно ли внешнее регламентное задание..." :)
(19) А на языке клиента ничего конкретного не было. Клиент сам не знал, от чего будут зависеть цены, и всё сводилось к обычному "сделайте, чтобы работало и мы могли сами поменять". Даже нормального ТЗ не состоялось.
(20) Возможно, скажу глупость, но - а какие тут могут быть взаимоблокировки? Это ведь справочник. чтение - есть чтение, без блокировки для изменения. Каждое действие происходит только с одним элементом, чистая объектная блокировка силами платформы. Или я не понял, о чём речь?
Насчёт возрастания сложности на порядок - не соглашусь. Если не дорабатывать сам механизм, а просто его юзать, то ничего особенного, сужу по своим коллегам.
(20) Возможно, скажу глупость, но - а какие тут могут быть взаимоблокировки? Это ведь справочник. чтение - есть чтение, без блокировки для изменения. Каждое действие происходит только с одним элементом, чистая объектная блокировка силами платформы. Или я не понял, о чём речь?
Насчёт возрастания сложности на порядок - не соглашусь. Если не дорабатывать сам механизм, а просто его юзать, то ничего особенного, сужу по своим коллегам.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
Открыть
|
Перенос данных КА 1.1 / УПП 1.3 => БП 3.0 (перенос остатков, документов и справочников из "1С:Комплексная автоматизация 1.1" / УПП 1.3 в "1С:Бухгалтерия 3.0")
|
Перенос данных КА 1.1 / УПП 1.3 => БП 3.0
Открыть