Существует следующая задача:
Необходимо отслеживать некий статус документа, например, его оплату. Данный статус могут менять множество других документов.

Вопрос в том как данный механизм реализовать наиболее оптимальным способом?

При это есть определенные условия:
1. В день создается и отслеживается по статусам около 500 документов.
2. Пользователю требуется почти в реальном времени видеть изменения статусов.

Пытался реализовать 2 способами:
1. Самый универсальный: регистр сведений, с измерениями СсылкаНаОбъект, ВидСтатуса и ресурсом ЗначениеСтатуса. Но тут сразу же возникла проблема быстродействия, дело в том, что список документов необходимо регулярно формировать с отборами как по реквизитам документа, так и по значениям статуса, что оказалось весьма тяжелым для БД.

2. Чуть менее универсальный: тот же регистр сведений, только все возможные виды статусов заранее развернуты в виде ресурсов. Чуть быстрее, но проблему быстродействия не решило.

3. Самый быстрый метод: добавление реквизитов в документы для нужных статусов. Отборы работают быстро (с составными индексами, конечно). Но, само решение кривое до тошноты, ведь статус объекта и сам объект - логически разные вещи, и тот факт, что другой документ при проведении меняет реквизиты другого печален. (Как изменять реквизиты - с помощью средств 1С или прямыми запросами не принципиален).

Вобщем, основной критерий - скорость. Спасибо.

Книга знаний: Множественный отбор в журналах и справочниках 7.7 заменой запросов SQL
Книга знаний: Отбор по нескольким реквизитам в журнале (www.sinor.ru)

ну так способ 3 всегда быстрее будет...

Может кто уже сталкивался с таким вопросом  нашел более элегантное решение?

А что, изменение статуса документа влияет на обработку его проведения?
Если нет, тогда 3 - лучший, и никакой печали.
Хуже, если да - всю цепочку придётся отслеживать, извраты вставляя.

(0) Гм, а в каждый документ засунуть реквизит в шапку - элемент специального справочника СвойстваДокумента.
А уже конкретный элемент этого справочника и иммеет нужный реквизит статус.
Соответсвенно нужно в каждом Свойстве иметь обратную ссылку на документ чтобы можно было по статусам выйти назад на документы.
При этом при проведении не меняется занчение реквизитов других документов, меняем только этот спец справочник.

(5) чем это лучше регистра сведений????

(5) Чем принципиально это решение отличается от регистра сведений? Мне кажется, с точки зрения таблиц БД это одно и то же.

(6)(7) Скоростью получения статуса документа

(8)+ и соответственно скоростью установки этого статуса для конкретного документа

(4) Изменение статуса документа влияет только на саму возможность его перепроведения или изменения. На результат проведения документа значения его статусов никак не влияют. Хотя и в этом случае печали немного есть - блокировки при одноврменной работе с самим документом и документом, изменяющим его статус.

(8)(9) Выйгрыша в скорости получении статуса и его установки не могу усмотреть. Может я чего-то не вижу, но за счет чего будет ускорение?

(4) Кстати, извраты для отслеживания все равно пришлось делать (а-ля наследования), т.к. в некоторых случая статус осного документа зависит от изменения статуса другого документа третьим, а вот третий заранее неизвестен ;-)

(11) просто прочитать два реквизита(Документ.Свойства.Статус) против запроса (по сути) к регистру сведений
(12) Можно заодно и решить, записав этот третий документ(или второй) в Свойства

Garykom - мне казалось, что обращение к реквизитам через точку пагубная тенденция, т.к. по сути это маленькие запросы. Поправьте, если я не прав

(12) - типа биномчика чтоль? Вводи неопределённые статусы.
Пробуй через рекви - строчный для увеличения скорости.
Можешь и значения статуса в глобальнике в переменные засунуть и оперировать ими - получишь прибавку в скорости.

(0) Имхо - путаем понятия о статусе:

При использовании типовых, где документы проводятся

В перечене статусов(например)
 Подготовлен (Записан    - факт наличия в ИБ)
 Оформлен    (распечатан - доп регистрация, но никак не в документе)
 Отгружен    (или отдельный документ или доп. регистрация в момент печати
              хотя принтер тоже может поламаться :))
 Оплачен     (документ оплаты >> состояние регистров)

Статусы Подготовлен и Оплачен - "выбиваются" из общей методы.

Я делал справочник с реквизитами:
ОбъектДокумент(Отбор), Статус.
Последовательная запись элементов справочника - что-то вроде регистра сведений
Последний элемент - актуальный статус.

А проведение основных документов, зависящее от проведения вторичных, перенести в модуль проведения вторичного не пробовал?
Если есть возможность определения "зависимых" доков, то переноси.

+(17) тогда левые статусы нах.. не нужны.

(0) Юзай бизнеспроцессы и не иппи мосх...

"Юзай бизнеспроцессы" и "не иппи мосх" - это взаимоисключающие понятия, хотя, для (0), мне тоже кажется, лучшее решение

У меня для заявок на склад реализовано такое на собственных табличках в СКЛ
(пара таблиц)
В журнале - текущий статус, в "журнале с отборами" отбор по любой стадии и т.п.
Видно кто и когда с точностью до долей секунды произвел операцию с доком
Также есть возможность строить отчеты по анализу заявок и для оплаты сотрудников (позиции, время между этапами и проч.)
В наибольшей таблице уже более 300 тыс. записей, только сегодня прикрутил 2 индекса :)

в (0) попытка х..м срубить дуб, конечно если дуб - х..вый, а х..й - дубовый - то можно...
> При это есть определенные условия:
> 1. В день создается и отслеживается по статусам около 500 документов.
> 2. Пользователю требуется почти в реальном времени видеть изменения статусов.
...полная бредятина в части "реальном времени видеть изменения статусов." - в реальном мире один юзер на постоянной основе сможет макимум реально ОТСЛЕЖИВАТЬ 20-30 доков, не просто тупо смотреть на картинку из 500 "доков", а именно ОТСЛЕЖИВАТЬ... какая польза юзерй в том что он будет отслеживать, к примеру, что 450 доков УСПЕШНО ПРОШЛИ ОПЛАТУ - т.е. ОТКЛОНЕНИЙ НЕТ. какую полезную инфу сможет юзер их этого почерпнуть и куда-то направить...? никакой...
ОТСЛЕЖИВАТЬ ИМЕЕТ СМЫСЛ ОТКЛОНЕНИЯ ОТ "ШТАТНЫХ" СИТУАЦИЙ, которых существенно меньше.. все что надо - сесть и денек-второй подумать, какие участик/переходы между статусами являются КРИТИЧНЫМИ ДЛЯ КОМПАНИИ/ПРОЦЕССА - только их и отслеживать... конечно, если 500 доков - это и есть отклонения от штатной схемы - тогда ой, тогда не программить надо а увольнять руководителей/менеджеров...

(22) Отслеживать может помогать вумный капутер, прикинь?
Допустим, за одной стадией следует другая и никак иначе, документы сортируются так  и сяк
Кроме того вряд ли один юзверь создал все эти 500 доков, он будет тупо смотреть на СВОИ 30 :)

(23) +1
про то и речь в (22), причем в (0.2) ничего не сказано про пользоватЕЛЕЙ, сказано пользоватеЛЬ, хз.. може там у них один оператор за всем следит... мутант такой...

(22)(24) Речь идет, конечно, о пользователях, каждый из которых отслеживает по 20-30 доков. Вернее сказать не то, чтобы непрерывно сидит и смотри за ними. Но, часто возникают моменты, когда пользователю(ям) нужно через несколько секунд узнать о том, что данный документ оплачен, отгружен и т.д.

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

(16) Собеседник, если я правильно тебя понял, то мы говорим об одном и том же. С той лишь разницей, что в моей случае статусов у документа может быть несколько, так как связь между ними можут быть слабой или отсутствовать. Например, статус оплаты (который имеет значения - не оплачен, частично оплачен, полностью оплчен, аванс) и статус отгрузки (Не отгружен, частично отгружен, полностью отгружен) не всегда заввисимы между собой, поэтому включить эти значения в одну цепочку невозможно.

(15)А что есть биномчик? (кроме Ньютоновского ничего не приходит в голову). Мной был создан регистр сведений, в котором фиксируется зависимость одного документа от другого, который, в свою очередь, может зависеть от третьего и т.д. При изменении статуса любого документа, вызывается обработчик, проверяющий необходимость изменения статусов всех подчиненных (по регистру) документов и так по цепочке.

(17) Пробовал и частично перенес. Только в некоторых случаях, код проведения разрастается до невозможности (есть документ, который в худшем случае при проведении может поменять статусы у 20 подчиненных), т.к. для каждого подчиненного документа в цепочке свои условия проведения. хотя все это и вынесено в общие модули, но в любом случае поддерживать такой код сложно.

(19)(26) - создал отдельную тему, посвященную БП.
v8: Опыт использования бизнес-процессов

(28) - перенесенный код сложно поддерживать?
а обработчик, который нах.. не нужен, значит нет?
Могу подбросить текст одной из наших накладных -
какой-то олень бомбанул его на 120 листов -
я когда разбирался - весь пол зала ими выложил.
И то, я бы сказал, только в начале было сложно, пока не сориентировался.
А вообще, определись на методе, и на том что тебе всё-таки нужно,
а то хочешь и рыбку съесть и в армию не сходить.

(30) Дело даже не в том, что мне лень плутать в своих же дебрях, которые через пару месяцев я забуду и буду мучительно вспоминать. А дело скорее в том, что процессы в фирме могут меняться очень стремительно (что неоднократно происходило), и соответственно, их так же стремительно нужно отражать в ПО. Обсуждать это - отдельный вопрос, флейма на эту тему много. Но факт остается фактом, проектировать надо т.о., чтобы внесение изменений требовало минимальных усилий в купе с другими условиями (в моей случае это быстродействие)

(31) Ну дык вставь коментарии, оптимизируй код,
сделай распечатки и ложи их под подушку.
Тем паче, что у тебя так получиться минимум корректируемых модулей.

+(31) Пляши от последнего по вводу "влияющего" документа -
не знаю, что там у тебя точно,
но по идее все обработки проведения должны в нём собраться.

Спасибо всем откликнувшимся. Мысли пришли в порядок.

Таки я не понял, по 77 тема или нет?
Вроде в 77 нет регистра сведений...

(35) тема по 8, сорри перепутал

Тогда на меня не рассчитывайте

(36) ГЫЫ....