Пытаюсь заново переосмыслить подход к описанию комплектации изделий, вроде бы тема достаточно избитая и тем не менее.

шаг1. создаем талицу товаров и замыкаем ее на себя
получаем иерархию, для простоты и скорости делаем денормализацию, типа
уровень, терминальность.
МИНУСЫ:
1. при появлении нового товара с несколько отличающимися характеристиками требуется новая спецификация, типа появились болты с резьбой 5 мм вместо 4 мм хотя и те и те можно использовать при сборке данного товара.
2. разные серии товара могут отличаться очень незначительно с точки зрения спецификации, а при таком подходе нужно создовать новую спецификациюю

шаг2.создаем вторую таблицу для себя я ее называю "шаблон" это условное понятие сборочной единицы котороя связана один ко многим с товаром
можно вроде бы ее замкнуть на себя, а вроде напрашивается отношения вывести в отдельную таблицу ОтношениеШаблон типа ШаблонРодитель, ШаблонПотомок, получаем отношение таблицы шаблон многие ко многим со мой с собой, и вроде бы счастье, но при таком подходе иерархию я блогополучно потерял, а ведь по жизни она есть, один шабон конечно можно использовать в разных спецификациях но ведь внутри одного изделя иерархия есть.

шаг3 вроде бы напрашивается еще одна таблица назовем ее "спецификация"
ее делаем иерархией замыкая на себя делаем связ один "шаблон" связан со многими спецификациями, и одна "спецификация" связана со многими "товарами" и одновременно одни "шаблон" связан со многими ""товарами"

на этом пока мои мысли иссякли
Буду очень признателен за критику, ссылки, и свои предложения

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

Работаю на MS SQL 2000= решаемая задача, описание производства и склада,
суть производства в основном сборка из готовых комплектующих, достаточно широкого набора продукции, многие блоки в разных изделиях повторяются,
вопрос идентификации конкретного изделия не стоит, Очень не хочется с одной стороны множить спецификации до бескончности, перекладывая груз на пользователя и раздувать базу, с другой оставить структуру базы типа многие ко многим и все решать за счет логики приложения усложняя ее до бесконечности, хочется максимально использовать структуру базы.

Несколько уточнений:
создав таблицу типа "ШаблонРодитель", "ШаблонПотомок" отдельно от таблицы "Шаблон", иерархия конечно не потерялась, и вобщемто вроде бы вся необходимая информация для построения дерева (спецификации) остается, не понятно только как денормализовать эту таблицу чтобы с одной сторны упростить алгоритм, с другой повысить скорость, с третьей воспользоваться существующими алгоритмами для обработки дерева поl SQK. ведь после создания сама спецификация остается достаточно постоянной, получается что уровень стороки "ШаблонРодитель"-"ШаблонПотомок" есть величина переменная и является функцией от спецификации, Второй момент который мне кажется тоже достаточно серьезным сама таблица отношений позволяет задать любое сочетание между "ШаблонРодитель" - "ШаблонПотомок" а это мяго выражаясь не совсем так не мешало бы на уровне структуры базы наложить ограничение, что внутри одной спецификации должно быть дерево а не юбой произвольный набор. Что-то ни как не могу понять нужно ли вводить еще дополниетльную сущность типа "Спецификация" или "МестоШаблонаВСпецификации" или как то по другому????

olol!
Они должны быть в одной таблице “изделия”…
Другая – “спецификация” для связи изделий с комплектующими…

Если не сложно сколько таблиц и с какими связим ты используешь сейчас у себя: 3 ? "товар" "изделие" "спецификация" соотношением один ко многим, а "товар" имеет составной ключ базовый товар + характеристика (типа размер, цвет) я правильно понимаю твой подход или нет ???


P/S спасибо за участие

Насколько я понял подходы у Сереги и olol очень разные, в одном случае два дерева с отношением один ко многим в другом отношения выносятся в отдельную табицу и получаем многие ко многим

Попробую уточнить что под чем я понимаю:
1."товар" это то что указывается в накладной и то в чем считается остатки по складам, это может быть и материал, и комплектующие, и готовое изделие, и полуфобрикат, и даже услуга. у него есть имя,характеристики, состав, цены(закупки, реализации, себестоимость) и т.п. итого имеем таб:
--кодтовар
--имятоавар
--разноетовар
--кодШаблон
2."шаблон" это абстракция от "товара" это чертеж изделия (для имени здесь скорее подходит код чертежа), или можно сказать что это строка спецификации, соответственно получаем таб
--кодШаблонон
--имяШаблон
--разноеШаблон

3. создаем таб отношений для шаблонов
--ШаблонРодитель
--ШаблонПотомок

4."Спецификация" это результат селекта



у Сереги и olol как я понял несколько по другому

Серега!
твой вариант для меня остался загадкой вроде я его и так повертел и эдак все равно не понял
Во первых если ты сразу делаешь дерево не выводя отношений в самостоятельную таблу, то как получается что один потомок может иметь разных Родителей, какой нибудь болт может входить у уйму разных, узлов
Во вторых если под "Деталью" ты пониаешь то что я для себя назвал "шаблоном" а под "спецификацией" --"товар" ???
то тоже что то странно кол-во поидее нужно указывать в "Детали" тогда или ты просто опустил таблу что я на зываю "товаром"
Если не сложно в чем фишка когда ты связываешь одно дерево с другим отношением один ко многим.

olol!
спасибо за подробное описание
как я понял что у тебя сейчас понятие "товар" и "изделие" в одной таблице
под "товаром" мы вроде пноимаем одно ито-же, а то что ты называешь "изделием" я называю "шаблоном" ??? так, и ты считаешь вполне разумным их раделить,здесь я полностью согласен, отношения между "изделиями" ты ваносишь в отдельную таблу по аналогии как я выношу отношения между "шаблон" , здесь мне тоже понятно, но как я понял что если бы ты разделил описание товар-изделие на две таблицы "товар" и "изделие", то стал бы делать отношение для "изделий" в одной табл "Спецификация" и еще одну табл "шаблон" для оношений "товар" - "изделие" тем самым формируя между ними связь многие ко многим, а резве недостаточно оношения один ко многим, задумку этой таблицы я не смог понять, таблица варианты мне как то тоже не совсем понятна, если ограничится признаком "основной/дополнительный" то достатчно просто еще одного поля в таб "товар" можно с историей и вариантами, а связь со "спецификацией"
тем более что в твоем предложении это таблица отношений, а не таблица сущностей, мне кажется несколько не понятной.




Сейчас мне кажется интересным следующий вариант в дополнениие к тому, что я писал раньше добавить следующее табл "товар"
разделить на следующие "БазовыйТовар", "ТипТовар", "ЗначениеТипа", Табл "Товар" будет выглядеть так
--КодБазовыйТовар
--КодТипТовар
--КодЗначениеТипа
(эти три строки является составным ключом, может даже два типа сделать?)

далее с "шаблоном" можно связать или "БазовыйТовар" или "Товар",
а может объеденить "БазовыйТовар" и "Шаблон"

когда будет формироваться накладная, должен задаваться базовыйтовар,
типтовара, значениетипа Например, БотинокМужской, Цвет, Черный
(конечно должны быть какие то значениея по умолчанию , и нулевые значения
"БазовыйТовар" и "Шаблон" можно и нужно ли объеденять я пока не розбоался


Второй момент после создания таблицы отношений для "Шаблона" мне кажется будет любопытно попробовать создать отделбную сущность "Дерево"она будет денормализована, и вней хранить образцы "Деревьев" типа
--кодДерева
--родитель
--Потомок
--уровень
--терминальность
--номер ??


и усановить связь одни "шаблон" ко многим "Деревьям" или с узлом дерева,
выделив может его тоже в отдельную таблу

или как то так пока это не решения а направление для мысли

А я их не связываю. Я на основе первого мышкой строю второе.

тогда понятно


В таблице Детали находятся только уникальные детали у которых не может быть разныз родителей.

это теперь тоже понятно
но ведь хочется чегото красивого и вечного (шутка)

Вот уж действительно: чужая душа - Потёмкин...
А насчет конструкторов/плановиков - твоя ситуация не уникальна.

Общим мне кажется следующее:
При описаниик комплектации, спецификации, сборки выделяются две сущности реальный товар и его абстракция и по умолчанию это две разные таблицы У Сереги Реальный Товар-"Спецификация", Абстрактный-"Детали", У Olol "Изделие" и "Товар", у меня "Шаблон" и "Товар", далее для каждой из сущностей строятся "отношения" или в отдельной таблице или замыканием таб на себя. Хотя мне кажется это не самый эфективный способ, я начинаю склоняться к мнению что "Абстракция" должна быть частью составного ключа
"РеальногоТовара", тогда и "ОтношенияАбстракций" будет одновременно и "ОтношениемРеальныхТоваров". "Отношения" мне кажется все таки надо обязательно выносить в отдельную таблицу а не как у Сериги замыканием на себя, здесь конечно появятся дополнительные заморочки, что в одной таблице "отношений" будет много "деревеьев" и нужно вводить как минимум или дополниткльное поле "ТипОтношений" или для каждого типа отношений строить свою таблицу "Отношений".
"Абстракцию" делать сотавным ключом "РеальногоТовара" тоже можно делать по разному, или по простому в таблице "РеальныйТовар" сделать поле IDАбстракция, связав их один ко многим напрямую, или выделив в отдельную таблицу, но это уже вроде перебор. Итого "Реальный Товар", будет иметь сотавной ключ "Абстракция", "Набор-параметров-и их значений".

Серега h2ospbПри описаниик комплектации....
Запутался я в твоих терминах. "Детали" у меня просто справочник уникальных деталей . Деревянная структура его - просто навеска для облегчения работы и улучшения наглядности - он может быть и плоским, это не принципиально . А "Спецификация" - это описание реального товара через соотношений уникальных деталей.


я об этом и говорю что такой подход когда уникальные товары и реальные это разные таблицы это не есть идеал, напрашивается , что бы "Детали" были составеным ключом "Спецификации" а сейчас у тебя слишком избыточные данные наверно это то же не единственный путь. или ты считаешь что я не о том??

Серега
Избыточность есть конечно. Но почему "слишком"? Значения в "Деталях" являются значениями "по умолчанию" для "Спецификации".

Например у тебя получается в "Деталях" есть строчка -карбюратор-,
а в спецификации -карбиратор, пластмассовый арт 124-, и вторая строка -карбюратор латунный арт 357- и тп.п конечно есть связь одни ко многим,

но можно подойти через составной ключ у спецификации
1 строка ключа IDДетали (в данном случае карбюратор),
2 строка ключа тип параметра (в данном случае материал)
3 строка ключа значение параметра (в данном случае, пластмасса или латунь)

4 строка уже не ключ артикул изделия

2 и 3 строка здесь смотрятся конечно несколько стремно и для реальной работы надо что то еще придумать типа один ID есть сочетание параметров и их значений или как то так, но суть в следующем что эти две таблицы уже совсем не то что когда есть отдельно "детали", и отдельно "спецификация" с отношением один ко многим, и дело не толко в сокращении объема данных , а прежде всего в том что отношение между "деталями" и отношнеие между "спецификациями" при это подходе одно и тоже.

[quot Серега]Ты веришь в идеальные решения?

quot]

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

СерегаНет. ----- Потом в "Спецификации" можно заменить любую деталь на любую другую (существующую уже в "Деталях"), например заменить в латунном карбюраторе прокладку на прокладку от пласмассового.
Непрошло и полгода как до меня дошло что ты делаешь, надо переварить, спасибо

у кого как работает теперь вроде бы понятно, интересно а какие прежде всего минусы каждый видит у себя и возможные способы их устранения????
НА мой взгляд общей какойто схемы врядли можно составить, но какие то общие моменты несомнено есть. В зависимости от задач подход может быть очень разный,
1.По умолчанию конечным результатом есть составление спецификации конкретного изиделя из конкретных комплектующих, (другое дело как это выглядит ипользуя, готовые узлы анологичных моделей, используя абстрактый шаблон из абстрактных изделий ),
но уже здесь есть масса нюансов, если даже у нас есть соответствующая структура и алгоритмы, которые позволяют это реализовать, то:
получается очень большое кол-во этих спецификаций, что может стать просто не посильной задачей для конечного пользователя (даже с учетом коприования и шаблонов), упорядочивание и структурирование и отслеживание изменений этих спецификаций становится отдельной и достатчно трудоемуой задачей. Компромисом на мой взгляд является сознательный отказ от задачи составить все эти спецификации, и ограничится только более общими спецификациями, например Спецификация ножа (какогото ножа не конкретного): лезвие (какоето), ручка (какаято), заклепки (какието). и все и не состовлять спецификации для ножа с деревянной , металической или пластмассовой ручки вообще. Тем самым абстрагируем уровень описание производства с конкретного изделия до абстрактного,
Опсиние склада и перемещение комплектующих и готовых изделий в поизводство и с производства мы продолжаем описывать в конкретных изделиях, и остатки на складах у нас остается в конкретных изделиях, а вот производство уже в абстрактных, при этом мы всегда по приходу и расходу пожем понять каково распределение между абстрактным товаром и конкретным. Такие допущения мне кажется во многих случаях вполне уместны, при условии что производственный цикл относительно короток, и основные материальныее ресурсы на складе а не в производственном цикле.
2. По поводу описания самой структуры по умолчания подрузомевается иерархия внутри спецификации я для себя ее называю горизонтальной, но ведь еще есть и иерархия "классов" или как бы вертикальная, попробую объяснить что я имею вв виду: при описвнии "ножа", можно использовать понятие "Ручки", потом ввести понятие "РучкаДеревянная", "РучкаПластмассовая", "РучкаМеталлическая", Далее можно углубиться еще на один уровень "РучкаБерезовая", "РучкаДУбовая" и так далее, (Это не противоречит моему верхнему предположению поскольку я все равно оперирую абстрактными понятиями). на лицо явная иерархия, но вдругом направлении,
возможно что могут быть и другие направления.

P/S это вообщем не вопрос а мысли вслух

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

Здесь надо найти разумный комромис что важно а чем можно и пренебречь, заменили гайку, и перепсывать все спецификации где она участвует, пусть даже в полавтоматическом режиме я думаю это не правильно, другое дело, ручка , деревянна, березовая, березовая с дырочками, где здесь остановиться это вопрос конкретной предметной области, на на каомто моменте надо остановиться обязательно. Объем работы должен быть реальным иначе он становится бесмысленным.

Серега
Есле бы ты сейчас стал заново преписывать структуру и решил бы это сделать по уму, то по какому пути ты пошел бы ???

p/s я прекрасно понимаю что лучшая структура эта та котоая есть и работает

Серега Ты думаешь, что этот мой вариант был сделан за 2 дня?

Но это было на "прошлой работе".

Конечно нет, только копирование веток дерева не делается за две минуты,
и для меня было очень интерсно разобрать твой вариант.Хотя использовать это у себя скорее всего небуду. В любом случае признателен за обсуждение, и если вдруг это задача будет для тебя актуальной буду рад продолжить.