Имеет ли смысл иметь категорию с несколькими родителями? Есть ли альтернативы?

Короткий вопрос: Как управлять категориями продуктов, которые отображаются под несколькими категориями? Это вообще плохая практика?

Фоновая информация: У нас есть база данных продуктов с категориями, которая нравится:

Products

  -Arts and Crafts Supplies
    -Glue
    -Paper Clips
    -Construction Paper


  -Office Supplies
    -Glue
    -Paper Clips

Обратите внимание, что клей и скрепки прикреплены к обоим категориям. И хотя они отображаются в двух разных местах в этом дереве категорий, , они имеют одинаковый идентификатор категории в базе данных. Зачем? Две причины:

Категории назначаются атрибутам - например, скрепка может иметь вес, материал, цвет и т.д.
Продукты, присвоенные категории клея, отображаются под изобразительным искусством и канцелярскими товарами. Что и следовало ожидать - они являются тем же самым фактическим идентификатором категории в базе данных.

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

Мы используем вложенную модель набора, поэтому структура db, которую мы используем для поддержки, такова:

Category
----------
CategoryID
CategoryName


CategoryTree
------------
CategoryTreeID
CategoryID
Lft
Rgt

Итак, существует 1: M между Category и CategoryTree, потому что в дереве категорий может быть несколько экземпляров данной категории.

Существует ли более простой способ моделировать это, что позволит отображать категорию продукта в нескольких категориях?

Ответ 1

Я не вижу в этом ничего плохого, если это правда, что all Клей подходит как для поставок канцелярских принадлежностей , так и.

Ответ 2

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

Категория

ID Имя

SubCategory

ID CategoryID SubCategoryID

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

Ответ 3

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

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

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

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

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

Интересная часть - это выявление проблемы, а затем представить решение, которое отлично подходит для конечного пользователя.

Ответ 4

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

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

изменить

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

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

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

изменить

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

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

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