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

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

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

========
А то, что у данной модели холодильника на данной позиции используется другая деталь или вообще нет детали - это хранится физически в СУБД !?
Еще более бесплатный совет - лучше не пишите текстов вообще.
========

Блин, сегодня вечер Аншлага :)
Попытаюсь растолковать то что сказано. Есть две модели холодильника. У одного ручка на морозильной камере пластиковая, у другого - модный аллюминий. Так вот, чтобы не плодить одинаковые документы из-за одной детали - делают групповую спецификацию. В групповой спецификации эти отличия (одной модели от другой) называется вариантами исполнения. А в базе данных храниться полный BOM привязанный к базовой модели и изменения для вариантов. Хотя у кого как реализовано.

Инженер планового отдела чего?

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

Сахават, я вообще не пойму о чем он. Похоже на то, когда разговор идет о производственном заказе, а он говорит: нет никаких производственных заказов, есть таблицы WorkOrder и WorkOrderDetail в базе данных, а производственный заказ - теория ... Это так, образно. Я такую дрянь не курю, поэтому понимания достигнуть сложно.

GaryaГоспода, будьте пожалуйста корректны друг к другу. Насмешки не в лучшем свете показывают тех, кто их использует вместо аргументации.
Приношу извинения