многие ко многим внутри одного стола

Question

У меня есть отношения, в которых моя таблица продуктов содержит сырье, сборочные узлы, сборки и т. Д. Все они называются «продуктами» с уникальным производством.Я не думаю, что это соответствует спецификации, потому что спецификация состоит из материалов, сливающихся для создания сборочных узлов, слитых для создания сборок и т. Д.

Это означает, что одна партия сырья может использоваться во многих сборочных узлах,и один узел может иметь несколько партий сырья.Эта новая сборочная единица может использоваться во многих сборках и наоборот.Это отношение «многие ко многим», но на бесконечных уровнях объединение двух таблиц не будет работать (например, материалы, таблицы сборок, если бы у меня было только эти два уровня).

Многие родители, много детей внутри одной таблицыи нанимаемая модель, похоже, обрабатывает обычную нанимаемую систему.

Могу ли я создать "семейную" таблицу с id_Parent и id_Child обоими ключами для одного идентификатора в таблице продуктов?Таким образом, я мог бы повторить один родитель для нескольких детей или один ребенок для нескольких родителей.

Есть ли другой / лучший способ сделать это?

Answer 1

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

Я реализовал это с двумя таблицами:

Product (product ID etc)
Components (Parent product, child product ID, quantity)

Это работает очень хорошо. В SQL Server вы можете довольно легко запросить его с помощью общего табличного выражения, чтобы установить «листья» любой данной спецификации.

Будьте осторожны при использовании таблицы компонентов. В этом примере таблицы продуктов и компонентов вместе дают шаблон для сборки комплекта / сборки. Для последующих отчетов вам нужно эффективно взять копию (или, если хотите, «экземпляр») спецификации и сохранить ее в другом месте. Вероятно, я бы попросил Product и Component описать спецификацию для сборки, а ProductItem и ComponentItem описать фактическую сборку, представляющую реальный элемент после того, как сборка состоялась.

Вы могли бы сказать Product / Component относительно Class, а ProductItem / ComponentItem - object в том смысле, что второй является экземпляр первого.