Разрешение категории иметь несколько родителей имеют смысл? Есть ли альтернативы?

То, что у вас есть, хороший способ, хотя почему бы не упростить вторую таблицу следующим образом:

Категория

ID Имя

Подкатегория

ID CategoryID SubCategoryID

Хотя в будущем я бы опасался разделения дочерних категорий между двумя корневыми категориями. Иногда для единообразия лучше создать уникальную категоризацию продуктов, которой легче управлять для вас и, возможно, легче ориентироваться для покупателя. В противном случае возникает проблема: если вы находитесь на странице «Клей» из канцелярских товаров, вы показываете и другой путь? В противном случае у вас будут две идентичные страницы, за исключением пути, который является проблемой для SEO. В противном случае пользователь может запутаться.

Самый известный пример - Google Mail, где классификация выполняется таким образом. Google славится удобством использования своих продуктов ...

Я считаю, что другие слова предпочтительнее "родительского" слова, которое на самом деле предполагает только связь XToOne ...

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

Это высветит проблему: если вы не ограничиваете количество категорий и отображаете категории с подкатегориями и так далее, вы можете заканчиваются:

• огромным списком категорий и продуктов с множеством дубликатов
• большой глубиной (вероятно, нечитаемой)

Интересная часть подчеркивает проблему,

Для категории может быть необходимо иметь несколько родителей. Однако, вне зависимости от того, в каком родительском элементе вы нашли категорию, ее подкатегории должны оставаться неизменными.

Я видел реальные системы, которые реализовывали именно эту логику и работали нормально.

править

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

Так, например, вы можете включить категорию клея как в канцелярские товары, так и в принадлежности для хобби, и если вы добавите «Безумный» Клей (Suppository Edition) »под клеи, это проявится в обоих. Если у вас есть элементы, которые могут быть сгруппированы логически, но должны быть разделены по их использованию, вы все равно можете это сделать. Вы можете отнести клейкий материал и пасту к категории клея для хобби, которая относится к корню хобби, но не к корню офиса. Или вы можете сделать это и одновременно создать комбинированную категорию, которая будет использоваться вашими покупателями внутри компании. Чего вы не можете сделать, так это забыть включить этот новый тип клея во все соответствующие категории после того, как вы добавили его туда, где он принадлежит вашей онтологии бизнес-модели.

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

edit

Предполагая, что я привел убедительные аргументы в пользу самой модели, остается проблема реализации. Есть много вариантов, но есть один путь:

Существует таблица CatalogItem, содержащая синтетический первичный ключ, метку, необязательный текст описания / подробностей и необязательный SKU (или эквивалент). Затем у вас есть CatalogItemJoin «многие ко многим» с дочерним и родительским идентификаторами, обе стороны ограничены CatalogItemTable.

Элемент, который отображается как родительский, является категорией, поэтому у него не должно быть SKU. Товар, который отображается только как дочерний, является продуктом, поэтому у него должен быть артикул. Для любого предмета нормально иметь более одного родителя; это просто означает, что он находится в нескольких категориях. Точно так же нет проблем с несколькими дочерними элементами на одного родителя; это будет типичный случай категории с несколькими товарами в ней. Однако, учитывая идентификатор категории, ее дочерние элементы будут одинаковыми, независимо от того, какая родительская категория привела вас туда.