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

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

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

Answer 2

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

Категория

Идентификатор Имя

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

ID Идентификатор категории Идентификатор подкатегории

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

Answer 3

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

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

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

---

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

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

Самое интересное — выделить проблему, а затем представить решение, которое подойдет конечному пользователю.

Answer 4

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

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

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

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

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

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

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

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

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

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