Прошу поделиться соображениями по следующей задаче.

Есть иерархические структуры - комплекты изделий, с уровнем вложенности не более 5.

Цена на комплект может меняться в зависимости от структуры комплекта. Не от номенклатуры, а именно от структуры. То есть цена комплекта это сумма всех деталей входящих в комплект и минус скидка за вхождение определённых деталей в определённую ступень иерархии комплекта.

Уф...

Комплекты ко всему ещё и меняются во время эксплуатации ПО. То есть пользователь должен иметь возможность "нарисовать" дерево комплекта - укомплектовать детали на различном уровне и установить зависимости на скидки.

После этого всё это дело должно продаваться.

Я понимаю что тяжеловато, но может кто-то уже сталкивался.

Заранее, спасибо.

freestyle,

Спасибо. Кручусь вокруг. Но смущают меня эти обходы по дереву и вообще всё что связано с иерархическими структурами.

Есть опыт работы с ними? Фокусов не будет на тысячном комплекте? Типа мемори аут?

Может быть лучше заранее забитая ненормализованная структура и куча полупустых таблиц?

На самом деле задача сложнее - там ещё зависимость цены от даты и структуры других комплектов.

То есть скидка на комплект Б предоставляется если заказчик уже брал комплект А не позднее одного года назад.

freestyle,

Спасибо.

А если усложнить ТЗ.

Пусть есть дерево комплекта с ветками. Я даю скидку если товар Б присутствует в ветках 1 и 2. А клиент хочет комплект без ветки 2.

Делать два разных комплекта? Но заранее предсказать все варианты комплектов практически невозможно. Или спроектировать возможность для клиента включать определённые ветки в комплект самостоятельно? Это реально?

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

Bely,

Правила достаточно сложные. Точнее простые но сложные для алгоритмизации. Есть зависимости типа "Если документ А был получен в ветке 2, дела Б не позднее года назад тогда скидка 30%"
Правила склдываются из множественных зависимостей между различными атрибутами документов, такими как дата, наличие, количество, язык, страна. То есть каждое конкретное правило простое, но процедура - это будет целый сложный парсер, со всеми вытекающими.

guest_20040621,

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

ладно буду воевать. получиться что то оригинальное кину решение сюда.

жду любых предложений и обсуждения.

авторЯ вам больше скажу: есть куча готовых open source rule engine на любой вкус. Выбирайте и пользуйтесь.

Спасибо, поищу.

авторОно вам действительно надо?

Во-первых, интересно; во-вторых, кушать хочется; в-третьих, уже вожжа под хвост попала; в-четвёртых, ковыряясь с иерархическими структурами и метаданными чувствуешь себя причастным к чему-то таинственному и очень важному :)

В целом у меня пока четыре сплетённых дерева метаданных. Этапы. Документы. Атрибуты. Заказы. Сиквел говорит что у него нет корректных инструментов для работы с данными структурами (MSSQL2005 библия пользователя).

Одно дерево, или сеть, можно легко заполнить но сложно извлекать.

Два взаимопересекающихся дерева сложно и заполнить - для заполнения одного нужно сразу извлекать из второго.

Про четыре я молчу, хотя это увеличение сложности экстенсивное, количественное.

Эта модель корректно хранит всю реальную систему. Но работать видимо с ней невозможно. Да и опыта маловато.

freestyle,

asp

чувствую, что без тяжёлого клиента не обойтись.

excell замечательно подходит :)

guest_20040621>

Достаточно выделить документы и процессы.

К сожалению нет. Это было бы просто. Самое неприятное это как раз система скидок, которая зависит от атрибутов типа время, цена, наличие, страна.

Приступаю к тестированию следующей модели.

Есть два дерева Комплекты и Документы, реализованные с помощью иерархических таблиц.

Стыкцются они в таблиуе Точки. В ней же назначается фиксированная цена.

Покупатель будет набирать себе необходимый динамический набор веток Комплектов.

Есть таблица Скидки и таблица Условия. В Условиях в качестве записей параметризированные запросы.

После добавления ветки Комплекта, тригер просчитывает необходимые условия и формирует таблицу Скидки.

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

Отказаться от борьбы с заумностями помогло вступление к библии пользователя МССиквела 2005. Всем настоятельно рекамендую первые 150 страниц прочитать и использовать в повседенвной практике дух и букву.

О результатах тестирования сообщу. Правда пока не знаю как запускать запросы которые храняться как запись в таблице.