Моделирование базы данных: продукт с 1 или более категориями

Question

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

==================
product
==================
product_id
name

==================
category
==================
category_id
parent_category_id
level
name

==================
product_category
==================
product_id
category_id (leaf node only)

Вопросы

1. Хорошо ли выглядит дизайн?
2. Прав ли я только бытьсвязан с листовым узлом в product_category-> category_id?(Я полагаю, что я могу пройти путь от конечного узла до корневого узла с этой информацией)
3. Учитывая продукт, как бы я получил дерево (и) категорий, к которому принадлежит продукт?
4. Учитывая категорию (любой уровень в дереве категорий), как я могу получить количество товаров, классифицированных под ней?
5. Любые другие запросы, которые мне нужно изучить?

Answer 1

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

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

Прочитайте: http://articles.sitepoint.com/article/hierarchical-data-database

---

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

Answer 2

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

CategoryId    Name
==========    ==========
1             Food
11            Chocolate
12            Dairy
121           Yoghurt
2             Grocery
etc...

Если это пригодно для использования в вашем домене, думаю, это может упростить ваш дизайн.

Answer 3

1. Да - таблица пересечения многих ко многим верна (товар может быть в нескольких категориях, в категории более одного товара).

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

3. Внутреннее соединение в таблице product_category (дайте мне знать, если вы хотите увидеть SQL).

4. Учитывая категорию (любой уровень в дереве категорий), как я могу получить количество продуктов, классифицированных по ней?(Это легко сделать с помощью объединения и подсчета - та же заметка, что и выше).

5. Скорее всего, вы будете открывать больше запросов по мере продвижения вперед, но в этом и прелесть возникающего дизайна:)