Для построения структуры подчиненности и прочего.

У РС в активе - поиск "вверх" простой, поиск сразу по куче документов, в пассиве - необходимость его заполнять и поддерживать целостность

У критерия отбора - "универсальность" с типовыми, простота добавления, меньше кода и более быстрая работа (не упирается в одну таблицу), в пассиве - кривота получения полной структуры при обходе "наверх"

За что голосуют 1сники?

Стандартизации ради и универсальности для...

А по велокатам вроде фиксин спец...

(2) так пятница же

Вопрос в "и прочего", имхо

(4) ну хз. может я в СКД хочу структуру подчиненности запилить

все работают, или всем пофиг?

(6) Мне пофиг.
Я не лазил во внутренности КритериевОтбора, потому что
1) Некогда
2) И не нужно

+(1) это ж по сути отчет для 1ого дока, там производительность не так важна, поэтому и поиск вверх можно сделать.

Вместо изобретения велосипедов лучше мисту почитать.

в нетленке решил проблему след. образом
у каждого документа есть экспортная функция в модуле ПолучитьСвязанныеДокументы() и ПолучитьВерхнийДокумент()
допустим, надо посмотреть подчинённость документа Расход товара

ПолучитьВерхнийДокумент() возвращает Заказ покупателя
затем происходит рекурсивная работа функции ПолучитьСвязанныеДокументы()

http://savepic.org/4465911.png

данная функциональность позволяет строить строгие деревья бизнес-процессов
каждый документ знает частью какого бизнес-процесса он является
каждый документ знает каких потомков он имеет

Критерии отбора и Последовательности документов есть частные случаи РС

(12) и как же они хранятся в БД?

в смысле про критерий отбора

со временем и кривоту поборят, а у нас уже - херак - и всё готово

(14) я в концептуальном смысле, могли бы храниться

(16) если бы могли - то тогда можно было бы обратиться к "источнику" отбора, а не только к приемнику

(17) могли бы хранится и действительно могли бы обратиься, но 1С в своем движке этого не сделала

реально убивает - анализируем метаданные критерия отбора, из документа выбираем значения реквизитов, для них также анализируем и т.д....

(0) >более быстрая работа (не упирается в одну таблицу)
А сколько же там таблиц? o_O
И, отдельно, почему несколько таблиц быстрее?

(20) критерий отбора - это просто индекс по реквизитам. соответственно, запрос к виртуальной таблице - это объединение запросов к куче реальных таблиц документов и справочников

(21) IMHO индекс таки материализованный в виде таблицы. Но точно не знаю.

- не будет узкого горлышка в виде регистра (ведь туда будут все ломиться).
- никто не мешает реализовать свои виртуальные "таблицы-запросы" по метаданным критерия.

PS у РС вижу плюс в индексах.