Эта проблема с дизайном оказывается немного более "интересной", чем я ожидал ...
Для контекста я буду реализовывать любое решение, которое получу в Access 2007 (выбор невелик - требование клиента. Я мог бы быть в состоянии передать их в другой бэкэнд, но во внешний интерфейс должен быть Access (и, следовательно, VBA & Access SQL)). Два основных действия, которые я ожидаю от этих таблиц, - это пакетный импорт новых структур из плоских файлов и создание отчетов по структурам (с полной рекурсией всей структуры). Практически не удаляет и не обновляет (кроме целых деревьев, помеченных как неактивные при создании новой версии).
Я имею дело с двумя основными таблицами, и мне интересно, действительно ли у меня есть представление о том, как их соотносить: продукты и детали (есть и другие, но по сравнению с ними они довольно просты).
Продукты состоят из частей. Часть может использоваться более чем в одном продукте, и большинство продуктов используют более одной части. Я думаю, что нормальная таблица разрешения многих ко многим может удовлетворить это требование (в основном - я вернусь к этому через минуту). Я назову этот продукт-часть.
«Веселая» часть состоит в том, что многие части также состоят из частей. Еще раз, данная Часть может использоваться более чем в одной родительской Части (даже внутри одного Продукта). Мало того, я считаю, что число уровней рекурсии нужно считать произвольно эффективным.
Я могу фиксировать отношения с разрешением m-to-m из частей обратно в части, связывая каждую некорневую часть с ее непосредственной родительской частью, но у меня есть скрывающееся подозрение, что я могу настроить себя на горе, если Я останавливаюсь там. Я назову эту часть-часть. У меня возникает несколько вопросов:
Я заимствую неприятности, задаваясь вопросом об этом? Другими словами, я должен просто реализовать две таблицы разрешения, как описано выше, и перестать беспокоиться?
Должен ли я также создать ряды деталей для всех предков каждой некорневой детали с дополнительным столбцом в таблице для хранения числа поколений?
Должна ли часть продукта содержать строки для каждой части продукта или только корневые части? Если бы это были все части, был бы полезен индикатор генерации?
Я (только сегодня, из связанных вопросов) взглянул на подход к проектированию Nested Set. Похоже, что это может упростить некоторые требования (особенно в части отчетности), но размышления о создании дерева при импорте сотен (иногда тысяч) деталей в импорт продукта приводят меня в кошмары, прежде чем я даже засну. Мне лучше кусать эту пулю и идти вперед таким путем?
В дополнение к конкретным вопросам, приведенным выше, я был бы признателен за любые другие комментарии по структурному проектированию, а также за подсказки о том, как обрабатывать его, входящий или исходящий (хотя я боюсь, что не могу принимать предложения по изменению языка / среды СУБД).