Лучший способ хранения иерархических тегов

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

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

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

Как это хранить Дейта? Я открыт для использования любого типа СУБД.

enter image description here

6
architecture data-structures database-design design language-agnostic

6 ответов

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

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

5

Я думаю, что это самый простой путь для любой базы данных: tag (id, name, parent_id), где parent_id относится к id родительского тега.

4

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

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

например, список фильмов.

другой источник данных, его коллекция иерархических данных ("каталог теги").

например список стилей кино.

+---Styles
  +---Comedy
    +---KidsComedy
    +---SomeComedy
    +---LOLComedy
  +---Action
    +---SomeAction
    +---GrabYourCouchSofaAction
  +---Drama
    +---SomeDrama
    +---LotsOfTearsDrama
    +---EvenToughGuysWillCryDrama
  +---Horror
    +---SoftHorror
    +---HardHorror
    +---Gore
  +---SciFi

каждый фильм может быть связан с несколькими стилями:

  • "Звездные Войны:Скрытая Угроза": {"SciFi, "SomeDrama","SoftHorror", "SomeAction"}
  • "Стартрек: Первый Контакт": {"SciFi, "SomeDrama", "SomeComedy"}

С точки зрения дизайна базы данных вы должны иметь unleast 3 таблицы или объекты сущности:

  • Записи Списка = {ListEntryID, ListEntryTitle,...}
  • Жанры Фильмов Теги / Стили = {TagID, TagTitle, ...}
  • Стили Для Movie = {TagForListEntryID, ListEntryID, TagID, ...}

Удачи.

1

используйте формат XML, который поможет вам сохранить узлы как родительские и дочерние Он может иметь n количество узлов и легко формировать и обрабатывать. Примечание: ниже приведен только пример, поэтому таким образом вы можете обрабатывать данные.

<Menu>
  <Menuitem1>
      <submenu1>
         <submenu1>
            <submenu1.1/> 
          </submenu1>        
      </submenu1>
  </Menuitem1>

  <Menuitem1>
      <submenu1>
      </submenu1>
  </Menuitem1>
</Menu>

Я думаю, это может помочь вам.

0

Это как я бы подошел к проблеме:во-первых, я нарисую модель домена. В вашем случае это выглядит так:

List(1)----contains----(0..*)-->ListItem
ListItem(0..1)----hasTags--(0..*)-->Tag
Tag(0..1)-----hasSubTags---(0..*)-->Tag

эта проблема явно не оставляя места для сомнений.

теперь переведите это в модель данных. Это довольно просто: для каждого отношения введите подходящие сопоставления PrimaryKey-ForeignKey.Отношения "многие ко многим" следует разбить на два 1-м отношения, используя новую таблицу между ними.

модель данных, которую вы имеете на этом этап должен быть функционально правильно, но может иметь проблемы с производительностью. Теперь настало время сосредоточиться на запросах, которые вы хотите, и соответствующим образом оптимизировать структуру таблицы.

(еще одна аналогичная поездка уточнения, начиная с модели домена, даст вам дизайн для окончательной модели класса)

надеюсь, этот подход поможет.

0

посмотреть мой ответ здесь. Я храню родителей для всех уровней-построение дерева и запрос всех потомков чрезвычайно прост.

0