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

Question

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

Blog 
    id 
    title 
    description 

Episode 
    id 
    title 
    description 

Tag 
    id 
    text 

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

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

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

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

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

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

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

TaggedStuff

id 
source_type 
source_id 
tag_id 

Answer 2

Если я вас правильно понял, речь идет оптимизировать механизм поиска ... Так что имеет смысл сделать какой-то index_table и деморализовать данные там ...

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

вот почему оба варианты очень хороши)))

Answer 3

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

Итак, в таком проекте вы связываете теги-сущности с вашими ресурсами, имея отношение к их обобщению.

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