дизайн базы данных для маркировки нескольких источников (MySQL)

Question

Я работаю над проектом, в котором у меня есть следующие (отредактированные) структуры таблиц: (MySQL)

Blog
    id
    title
    description

Episode
    id
    title
    description

Tag
    id 
    text 

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

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

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

Первоначально я планировал создать несколько таблиц сопоставления тегов:

BlogTag
    id
    tag_id
    blog_id

EpisodeTag
    id
    episode_id
    tag_id

Но теперь мне интересно, было бы мне лучше:

TaggedStuff
    id
    source_type
    source_id
    tag_id

Где source_type будет целым числом, связанным с тем, был ли это эпизод, блог или какой-то другой тип, который я невключенный в структуры выше, и source_id будет ссылкой в ​​этой конкретной таблице.

Мне просто интересно, какова будет оптимальная структура для этого, первый выбор или второй?

Answer 1

В чистом (академическом) дизайне часто встречается супертип Resource (или что-то подобное) для Blog и Episode со своим собственным столом.Еще одна таблица для тегов.И так как это отношение N: M между Tag и Resource, у вас есть дополнительная таблица сопоставления между ними.

Таким образом, в таком дизайне вы бы связали Tag-Entities с вашими ресурсами, имея отношенияк их обобщению.

После этого вы можете добавить общие атрибуты к обобщению.(т. е. заголовок, описание) Вы можете добавить атрибуты в отношения между Tag и Resource, например, счетчик того, как часто конкретный ресурс был помечен определенным тегом.Или как часто использовался тег и и и и (то есть что-то похожее на стекопоток в правом верхнем углу)

Answer 2

Самая большая потеря при работе со структурой 2 - это потеря ссылочной целостности .Если вы можете сказать «что угодно», это может быть проще для этой структуры.

Когда я говорю структуру 2, я имею в виду:

TaggedStuff

id
source_type
source_id
tag_id

Answer 3

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

Я имею в виду что-то вроде этого: Url, Type, Title, Search_Field и т. Д. где Url - путь к статье или эпизоду, Type (article | episode), Name (что увидят пользователи), Search_Field (список тегов, другие важные данные для поиска)

, поэтому оба варианта довольно хороши)))