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

Question

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

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

Products

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


  -Office Supplies
    -Glue
    -Paper Clips

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

1. категориям назначаются атрибуты - например, скрепка может иметь вес, материал, цвет и т. Д.
2. Продукты, отнесенные к категории клея, отображаются в разделе «Декоративно-прикладное искусство» и «Товары для офиса». Что и следовало ожидать - это тот же фактический идентификатор категории в базе данных.

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

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

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


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

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

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

Answer 1

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

Answer 2

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

Категория

ID Имя

SubCategory

ID CategoryID SubCategoryID

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

Answer 3

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

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

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

---

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

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

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

Answer 4

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

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

редактировать

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

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

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

редактировать

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

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

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