Требуется спроектировать подсистему контроля ввода свойств характеристик для ЕРП. Собственно, суть задачи:
В форме, при выборе значений одних свойств, устанавливать ограничения и признаки на другие свойства.
Сложность в том, что условия нелинейные, т.е. типа: если значения свойства1 в списке или не значение заполнено свойство3, то свойство2 обязательно к заполнению и для использования недоступны следующие значения свойства2.
Планируется, что таких ограничений вводиться будет очень много и часто будут какие-то условия изменяться. Так же будут удаляться какие-то свойства/значений и надо при этом корректировать отборы с учетом этого.
Подобный механизм работает у клиента на УПП, где условия отбора распарсиваются и хранятся в регистре. Но работает он не очень быстро и малость глючно.
Собственно, тоже тут вижу необходимость использования отбора скд. Вопрос: как, ввиду вышеперечисленного, лучше хранить условия отбора?
  Пока придумал хранить сами условия отбора в справочнике, где каждый элемент - минимальное условие - ссылается на вложенные условия. Но сложность в отслеживании изменений уже существующих условий, так как в отборе СКД они никак однозначно не будут идентифицироваться. Планировал, что при корректировке отбора вся эта вложенная структура будет нахально удаляться из базы, а вместо неё будет создаваться новая.
  Вероятно, при таком подходе будет расти размер базы. Насколько это критично? Какие ещё подводные камни имеются?
  В регистре не хотелось бы хранить из-за того, что будут долго собираться условия, дольше, чем просто переходами по ссылкам элементов справочника.
  Просто сериализовать условия не вариант по причине того, что могут быть изменены свойства и значения, входящие в условия.
  Поделитесь, как реализовывали подобное, если имеете такое опыт?

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

(1) Вы расширили задачу, но не ответили на вопрос из (0) - как эффективнее хранить структуру условий. Да, так, конечно, будет более гибко. Но по условию заказчика, достаточно хранить отбор СКД.

Возник ещё вопрос: не получается вывести корректно на форму отбор по свойствам характеристик. Причем, в консоли СКД всё работает, а в обработке - нет.
Выглядит это так: http://snap.ashampoo.com/A0XXjY1aMheDlmr2nVwsSbteGUdTsJVSjoLSiGSUNxYzeKvrBMeUoXzUn5JAGaTq
Вот обработка, в которой необходимо устанавливать отбор по свойствам характеристик: https://yadi.sk/d/gknNjBWkI9WEyg
Платформа: 8.3.13.1513, 1С:ERP Управление предприятием 2 (2.4.10.62)
ЧЯДНТ?

Ап!

(0) >Планируется, что таких ограничений вводиться будет очень много и часто будут какие-то условия изменяться. Так же будут удаляться какие-то свойства/значений и надо при этом корректировать отборы с учетом этого.

Не взлетит это все ИМХО. Если не запутаешься ты при реализации, то запутаются пользователи при использовании. В УПП похоже так и было.

Такие задачи нельзя решать "универсально", в отрыве от предметной области.

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

(0) Используй хранилище

(7) Хранилище неудобно тем, что непонятно, как отследить изменение/удаление свойства/значения, входящего в условие.

(5) У них в УПП работает.

(6) Верно, это похоже на модель интернет-магазин и предназначено для подбора диллерами изделий по свойствам.

Коллеги, снова требуется ваша помощь. Структуру в (0) я спроектировал. С сохранением и хранением отбора всё в порядке. НО теперь не могу никак сообразить, как мне проверить то, что условия отбора выполняются. Есть, например, у меня такой отбор: http://snap.ashampoo.com/v3oyKTZWZGcipPmrxFkjXHz2KJWP7Cmt81MjphbkNDs7T0pLfZU7COznYr6WTJlS
И есть на форме выбранные значения свойств. http://snap.ashampoo.com/SR9o44DF9giHyBPywHwvwJKUU0UQfpVyBUh8rleQrMYkojDFrZ2iEG6ZgsLLCcfE
Мне требуется как-то понять, что выбранные значения свойств удовлетворяют отбору, например, представить условия отбора в виде кода. Только непонятно, как это сделать, чтоб было более-менее универсально?
Может вам приходилось решать подобную задачу? Поделитесь, как решали.
Заранее спасибо!

(0) (11) Тут проблема не в структуре (на нее пофиг) а в архитектуре и алгоритме.

Для начала выдели ограничение и признаки ("обязательно к заполнению", "недоступно" и т.д.)
А затем банальная булева формула.

Т.е. отдельная формула на каждое свойство для каждого ограничения и признака.
Как параметры формулы (которая возвращает истина/ложь) используются значения других свойств.
Или промежуточные булевы формулы.

(12)+ Только еще учти что могут быть введены такие "ограничение и признаки" которые противоречат друг другу.

Кстати задачка очень близка к ML и ИНС.
Набор признаков на входе, внутри что то происходит и имеем нечто на выходе.

Можно попробовать через ML и решать, заполнять "правила" на основе обучающих примеров.

Garykom, спасибо за предложенные варианты!
Я нашел следующее решение: создаю программно макет скд по объекту - таблице значений, в которой каждая колонка - название реквизита(свойство), а значение в колонке - значение свойства, выбранное в форме(в таблице только одна запись, к которую и помещаются значения). Отбор, накладываемый на таблицу преобразовал по аналогии. Таким образом, если отбор накладывается и запись удовлетворяет ему, то результатом выполнения компоновки является эта самая одна запись, а если не выполняется - то ноль записей.
Работает довольно быстро.