дизайн базы данных-категории и подкатегории [закрыто]

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

Предположим, у меня есть следующие таблицы:

Категории Стол

CategoryId, Title
10, Home
20, Business
30, Hobbies

у меня есть два варианта кодирования подкатегории.

Вариант 1-идентификатор подкатегории уникален только в категории:

Таблица Подкатегорий

CategoryId, SubCategoryId, Title
10, 100, Gardening
10, 110, Kitchen
10, 120, ...
20, 100, Development
20, 110, Marketing
20, 120, ...
30, 100, Soccer
30, 110, Reading
30, 120, ...

вариант 2-Subcategory Id уникален в целом:

Sub Таблица Категорий

CategoryId, SubCategoryId, Title
10, 100, Gardening
10, 110, Kitchen
10, 120, ...
20, 130, Development
20, 140, Marketing
20, 150, ...
30, 160, Soccer
30, 170, Reading
30, 180, ...

Вариант 2 звучит так, как будто легче извлечь строки из таблицы Например: SELECT BizTitle FROM tblBiz WHERE SubCatId = 170

в то время как с помощью опции 1 я должен был бы написать что-то вроде этого:

SELECT BizTitle FROM tblBiz WHERE CatId = 30 AND SubCatId = 170

т. е. содержащий дополнительный AND

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

какие-нибудь мысли об этом? Вариант 2 стоит проблемы с точки зрения эффективности? Есть ли какие-либо шаблоны дизайна, связанные с этой общей проблемой?

3 ответов


Я бы использовал эту структуру:

ParentId, CategoryId, Title
null, 1, Home
null, 2, Business
null, 3, Hobbies
1, 4, Gardening
1, 5, Kitchen
1, 6, ...
2, 7, Development
2, 8, Marketing
2, 9, ...
3, 10, Soccer
3, 11, Reading
3, 12, ...

подробнее:

  • используйте только одну таблицу, которая ссылки, так что вы можете иметь неограниченную глубину категорий
  • использовать техническая идентификаторы (через IDENTITY, или аналогичный), так что вы можете иметь более 10 подкатегорий
  • при необходимости добавить удобочитаемом столбец для категории-номера как отдельным поле

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

SELECT BizTitle FROM tblBiz WHERE ParentId = 3 AND CategoryId = 11

новая hierarchyid функция SQL server также выглядит довольно многообещающе:https://msdn.microsoft.com/en-us/library/bb677173.aspx


что мне не нравится в Вложенная Модель Набора:

  • установка и удаление элементы Вложенная Модель Набора является довольно сложным делом и требует дорогие замки.
  • можно легко создать противоречия что запрещено, если вы используете parent поле в сочетании с ограничением внешнего ключа.
    • несоответствия могут появиться, если rght is ниже чем lft
    • несоответствия могут появиться, если значение apprears в несколько rght или lft поля
    • несоответствия могут появиться, если вы создадите пробелы
    • несоответствия могут появиться, если вы создадите совпадения
  • на Вложенная Модель Набора на мой взгляд более комплекс и поэтому не так легко понять. Это, конечно, абсолютно субъективно.
  • на Вложенная Модель Набора требуется два поля, а не один - и поэтому использует больше дисковое пространство.

управление иерархическими данными имеет некоторые способы. Одним из самых важных является Nested Set Model.

посмотреть здесь для реализации.

даже некоторые системы управления контентом, такие как joomla, используют эту структуру.


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

  • фрукты
  • цвета

для каждого я хочу подкатегория

  • фрукты

    • Яблоко
    • оранжевый
  • цвета

    • Белый
    • оранжевый

обратите внимание, что оранжевый является подкатегорией в каждой категории. Хотя название то же самое, это функция очень отличается. (Давайте не будем вдаваться в возможность того, что оранжевые фрукты оранжевого цвета)

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

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